From alanb at openjdk.org  Mon Aug  1 06:09:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 06:09:39 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
Message-ID: <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>

On Fri, 29 Jul 2022 16:02:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Is there anything else to be done in this PR? Thanks.

It looks like this issue has changed from the original bug report and now rejects the empty pattern with IAE. This is a behavior change (and probably the right behavior) but I think will require a small update to the javadoc to make it clear that both an empty syntax and empty pattern are illegal.

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

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

From plevart at openjdk.org  Mon Aug  1 07:09:23 2022
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 1 Aug 2022 07:09:23 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: <unEeCjZyLCmSmkJZWV6q75XkzydRa2kV9SEEGpAYzMY=.a1d833ae-9015-4ae7-bd72-259bdcc41cca@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

...while waiting for a GC expert to confirm that writes, in program order preceding a call to reachability fence, are visibile to GC thread that discovers a phantom reachable referent, here is an example which illustrates that some writes at least "must" be visible for GC to function properly:


var ar = new Object[1];
var e = new Object();

ar[0] = e;
Reference.reachabilityFence(e);

// GC kicks-in at this point

var e2 = ar[0];
// use e2


A write to an array slot ar[0] must be visible to a GC thread when it searches for root(s) after the mutator thread's call to reachability fence. If it was not, it could miss that fact that object 'e' is still reachable. So GC must do something so that at least writes to reference variables are visible. If it does not distinguish reference writes from primitive writes, then it does the same for all writes.

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

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

From alanb at openjdk.org  Mon Aug  1 07:22:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:22:35 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this:


diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
index 1d55fa8e358..add48336d16 100644
--- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java
+++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
@@ -130,8 +130,9 @@ abstract class Task<T> implements Runnable {
                 .map(s -> s.substring(s.indexOf("java")))
                 .collect(Collectors.toList());
 
+        ClassLoader scl = ClassLoader.getSystemClassLoader();
         for (String name : fileNames) {
-            classes.add(Class.forName(name));
+            classes.add(Class.forName(name, false, scl));
             if (count == classes.size()) {
                 break;
             }

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

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

From shade at openjdk.org  Mon Aug  1 07:38:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 07:38:46 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <LlVLLSKlSWxzuVO-rsJrBWDWZyKHfw6pbG4UgWOHiHQ=.c330edd3-1fd9-4dfe-b869-5e3b9cc1dcb7@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

Hey @AlanBateman, welcome back? Please see if you agree with network tests change?

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

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

From alanb at openjdk.org  Mon Aug  1 07:47:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:47:37 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

No objection to changing these tests. We should probably do test/jdk/java/net/vthread/BlockingSocketOps.java at the same time as it also runs the sockets tests with the Poller in both configurations.

For the test ids then I'd prefer not use two styles (id=useDirectRegister and id=no-continuations). Can you change these to `indirect-register` and `no-vmcontinuations`?

I'd prefer if the `@bug` tag is not copied, only because we add to the bug list when extending tests.

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

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

From shade at openjdk.org  Mon Aug  1 08:37:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 08:37:11 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

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

 - Review comments
 - Merge branch 'master' into JDK-8290531-loom-tests-parallel
 - More fixes
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9554/files
  - new: https://git.openjdk.org/jdk/pull/9554/files/3f9bf337..e87544f2

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

  Stats: 16874 lines in 645 files changed: 10175 ins; 4817 del; 1882 mod
  Patch: https://git.openjdk.org/jdk/pull/9554.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9554/head:pull/9554

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

From shade at openjdk.org  Mon Aug  1 08:37:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 08:37:11 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>
Message-ID: <3PVri60xrVtIlINItS63CO_6IXUoP1EAn4gGPicrnVY=.4c531ba1-17bd-4a30-a8a6-7c7099c0a15e@github.com>

On Mon, 1 Aug 2022 07:43:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to changing these tests.

Did the changes in new commit.

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

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

From aoqi at openjdk.org  Mon Aug  1 12:02:02 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 12:02:02 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v2]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <Us2WLe6tvDTtiBgYBElsWmC_3OPgUAkagCIu45xbf3M=.c50985e0-e47b-49c2-b1e9-4ebd90963d52@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  XMLDecoder update
  
  Co-authored-by: Alan Bateman <alanb at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/c16a0b87..623e3723

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

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

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

From aoqi at openjdk.org  Mon Aug  1 12:04:41 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 12:04:41 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
Message-ID: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>

On Mon, 1 Aug 2022 07:18:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
>> 
>> The issue could be reproduced by zero.
>
> For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this:
> 
> 
> diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> index 1d55fa8e358..add48336d16 100644
> --- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> +++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> @@ -130,8 +130,9 @@ abstract class Task<T> implements Runnable {
>                  .map(s -> s.substring(s.indexOf("java")))
>                  .collect(Collectors.toList());
>  
> +        ClassLoader scl = ClassLoader.getSystemClassLoader();
>          for (String name : fileNames) {
> -            classes.add(Class.forName(name));
> +            classes.add(Class.forName(name, false, scl));
>              if (count == classes.size()) {
>                  break;
>              }

Hi @AlanBateman , your method works. It is a much better way. Thank you very much!

Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?

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

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

From alanb at openjdk.org  Mon Aug  1 12:44:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 12:44:33 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
Message-ID: <S-e8f6wYKjg01So4HDbC5tyFIYZY8cbcHiBp8ypQmVQ=.dc8a6287-987c-4bb3-b7b9-0359e5d82f42@github.com>

On Mon, 1 Aug 2022 08:37:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
>> 
>> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
>> 
>> 
>> # release before
>> real 4m41.424s
>> user 24m18.064s
>> sys 1m16.440s
>> 
>> # release after
>> real 2m47.769s   ; -40%
>> user 23m44.622s
>> sys 1m15.240s
>> 
>> 
>> # fastdebug before
>> real 5m38.078s
>> user 67m23.516s
>> sys 1m56.446s
>> 
>> # fastdebug after
>> real 4m9.249s    ; -26%
>> user 67m21.940s
>> sys 1m57.625s
>
> Aleksey Shipilev 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:
> 
>  - Review comments
>  - Merge branch 'master' into JDK-8290531-loom-tests-parallel
>  - More fixes
>  - Fix

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.org  Mon Aug  1 12:47:44 2022
From: duke at openjdk.org (Joe)
Date: Mon, 1 Aug 2022 12:47:44 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
Message-ID: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>

8289562: Change bugs.java.com and bugreport.java.com URL's to https

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

Commit messages:
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

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

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

From shade at openjdk.org  Mon Aug  1 12:55:52 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 12:55:52 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to newString646_US
 warning
Message-ID: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>

See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566

I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.

Additional testing:
 - [x] Linux x86_32 build with GCC 11
 - [x]  Linux x86_32 `tier1` test with GCC 9
 - [ ]  Linux x86_64 `tier1` test with GCC 9

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

Commit messages:
 - Another fix
 - Fix

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

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

From hseigel at openjdk.org  Mon Aug  1 13:33:00 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 13:33:00 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
Message-ID: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>

On Sun, 31 Jul 2022 22:05:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> src/hotspot/share/prims/jvm.cpp line 4064:
> 
>> 4062:   assert(c->is_instance_klass(), "must be");
>> 4063:   InstanceKlass* ik = InstanceKlass::cast(c);
>> 4064:   return (ik->minor_version() << 16) | ik->major_version();
> 
> I'm curious why the format is minor:major rather than major:minor ?

This was requested by @RogerRiggs 

Major high vs low bits requires either:
  High bits:   val >>>16
  Low bits:     val & 0xffff

Except for preview, the minor version is 0, so putting major version  in the low bits allows trivial comparison (without masking); but may lead to bugs due to carelessness.

> src/java.base/share/classes/java/lang/Class.java line 4698:
> 
>> 4696:      *
>> 4697:      * If the class is an array type then the access flags of the component type is
>> 4698:      * returned.  If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC.
> 
> The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice?

I don't know why API's such as JVM_GetClassModifiers() and JVM_GetClassAccessFlags return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC for primitives.  Nor could I find a spec that discussed access flags for primitives.  But, I didn't want to change what's been returned for primitives in existing code.

> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31:
> 
>> 29:  * @modules java.base/java.lang:open
>> 30:  * @compile classFileVersions.jcod
>> 31:  * @run main/othervm --enable-preview ClassFileVersionTest
> 
> What preview feature is being used here?

No preview feature is being used but --enable-preview is needed here for the JVM to accept a class with a minor version of 65535.

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

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

From rriggs at openjdk.org  Mon Aug  1 13:47:23 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 13:47:23 GMT
Subject: Integrated: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java
 fail: More or fewer pipes than expected
In-Reply-To: <cPRtX--gaAFyfoi6QA1o3tmkZXvaGzROkvVaKEuBZN4=.6e4b420d-bd96-4b34-ad3f-d2338efe83ec@github.com>
References: <cPRtX--gaAFyfoi6QA1o3tmkZXvaGzROkvVaKEuBZN4=.6e4b420d-bd96-4b34-ad3f-d2338efe83ec@github.com>
Message-ID: <r4tdAQFpRNDA2gxE-ZVazQ-UdcDzt6WZvsYy4eu-3Lw=.92f51385-1d03-4aa7-916c-be7b4beff692@github.com>

On Fri, 29 Jul 2022 16:49:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp.
> It reports extra file descriptors are open that not expected.
> The test of pipelines did not explicitly use or close the stderr streams of each stream except the last.
> The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced.
> 
> The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last.
> 
> The test is removed from the ProblemList-Xcomp.

This pull request has now been integrated.

Changeset: 226b8e68
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/226b8e680a82096b3d268703872d30182c10e326
Stats:     12 lines in 2 files changed: 7 ins; 2 del; 3 mod

8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected

Reviewed-by: bpb, naoto, jpai

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

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

From rriggs at openjdk.org  Mon Aug  1 14:04:46 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 14:04:46 GMT
Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content
 [v3]
In-Reply-To: <giGrookyHaGPl3emN1hHJNvgMBnKV1l7e_8xIYOc59s=.a4990eba-71a5-45e7-bca1-36625025ce41@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <yk2lTbFAA26vSWBxuuCELVYufd33slJ4P_8DZN6PdAo=.63e231f1-4ef3-4c3b-aa7c-467888b00894@github.com>
 <iKt-_Hy_pqoALXJBZnBeyGyiFpNUVTmZ0kWQW7DqAfo=.afb348a4-c072-4bd0-b844-5064b5cea254@github.com>
 <giGrookyHaGPl3emN1hHJNvgMBnKV1l7e_8xIYOc59s=.a4990eba-71a5-45e7-bca1-36625025ce41@github.com>
Message-ID: <JXFG6k1E4GqJ64dQyEhyBhNvDrcfyGZ5q6ByEJ0uD7k=.234b5033-7522-4e64-badc-5bc3194a09d3@github.com>

On Tue, 26 Jul 2022 20:52:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`.
> 
> OK, removed those two convenient APIs.

I expected much of the complexity of parsing and storing content transformed extension strings would be unnecessary without the APIs. The original string form of the extension should be sufficient for `Locale.getExtension`. It also adds quite a bit of complexity and overhead to getDisplayName to reconstruct the strings.  The correct syntax of the string can be checked with a RegEx in the builder. If a simpler implementation is sufficient, there is less code to maintain.

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

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

From rriggs at openjdk.org  Mon Aug  1 14:08:08 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 14:08:08 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <pX8prnJ_Ag1BhzmY1bKXtB9iE1rXZ32pNKcJR32w2Kc=.384bd443-2644-4b47-a405-18a484a3ccb9@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
 <rTPgulO7la9xj1mvPFuQ-AFYMAT7CsSUddKJg7t3nfg=.f363ad45-87fd-4f60-be78-7bb76a147be9@github.com>
 <xgwDK4cBoXpn0Vdot8yeldugje7kCuzMTy-eS-hTikY=.397c453e-8720-41ee-8f26-f62ad3ab2e3a@github.com>
 <pX8prnJ_Ag1BhzmY1bKXtB9iE1rXZ32pNKcJR32w2Kc=.384bd443-2644-4b47-a405-18a484a3ccb9@github.com>
Message-ID: <E68MNXQqW8adSa0fTRE2r9o-bNy_xy_frcuS3eZ1C34=.d4652e51-69c5-4ce8-b74a-79cb15537447@github.com>

On Sat, 30 Jul 2022 07:45:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side.
>
> Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is.

My companion question was whether the native code can for efficiently map from array class to component type than Java.

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

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

From shade at openjdk.org  Mon Aug  1 14:20:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 14:20:55 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
Message-ID: <vgBGKmXcKP2Hjb3kWT6oS39B-WcNuIMWwNMZBZmATVE=.9a3da547-b957-44fc-b536-7dbc27043127@github.com>

On Mon, 1 Aug 2022 08:37:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
>> 
>> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
>> 
>> 
>> # release before
>> real 4m41.424s
>> user 24m18.064s
>> sys 1m16.440s
>> 
>> # release after
>> real 2m47.769s   ; -40%
>> user 23m44.622s
>> sys 1m15.240s
>> 
>> 
>> # fastdebug before
>> real 5m38.078s
>> user 67m23.516s
>> sys 1m56.446s
>> 
>> # fastdebug after
>> real 4m9.249s    ; -26%
>> user 67m21.940s
>> sys 1m57.625s
>
> Aleksey Shipilev 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:
> 
>  - Review comments
>  - Merge branch 'master' into JDK-8290531-loom-tests-parallel
>  - More fixes
>  - Fix

Thank you!

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

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

From shade at openjdk.org  Mon Aug  1 14:24:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 14:24:47 GMT
Subject: Integrated: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <aywnpNsqfo_BDGclxNWitNCOiJRHljWhT_FGo1RS0Xo=.8545a854-ad24-4ac9-9773-e03ef50ca823@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

This pull request has now been integrated.

Changeset: fcc11953
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcc119531a3badaa5f7b5602b3d74c2ac5bf7b81
Stats:     42 lines in 3 files changed: 25 ins; 3 del; 14 mod

8290531: Loom: Parallelize a few tests more deeply

Reviewed-by: rpressler, jpai, alanb

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

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

From fmatte at openjdk.org  Mon Aug  1 14:32:47 2022
From: fmatte at openjdk.org (Fairoz Matte)
Date: Mon, 1 Aug 2022 14:32:47 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <yKAWQeCCkJiO3lvHnWLvEKVuWTt9R3JEkxgnIiEWW8E=.e48cfdf8-8fa0-47a1-bfb3-874bcffaadd7@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

It is a trivial change and looks good to me (I am not a reviewer).

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

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

From shade at openjdk.org  Mon Aug  1 14:50:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 14:50:48 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v2]
In-Reply-To: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
Message-ID: <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>

> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
> 
> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
> 
> Additional testing:
>  - [x] Linux x86_32 build with GCC 11
>  - [x]  Linux x86_32 `tier1` test with GCC 9
>  - [ ]  Linux x86_64 `tier1` test with GCC 9

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Init buf in newStringCp1252

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9702/files
  - new: https://git.openjdk.org/jdk/pull/9702/files/82ff99b3..adcbf91c

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

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

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

From hseigel at openjdk.org  Mon Aug  1 15:17:56 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 15:17:56 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
Message-ID: <c3-PAWogDiVrRB8g7BkGeVf7xYx5G17DNwmZBl-G8DE=.72b38442-8235-4b81-8cc9-c7ad39b3ea29@github.com>

On Sun, 31 Jul 2022 22:22:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55:
> 
>> 53: 
>> 54:         testIt("Version64", 64);
>> 55:         testIt("Version59", 59);
> 
> Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions?

No particular reason for choosing 59 other than it's different and less than 64.  Test case Version64_65535 has a non-zero minor version.

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

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

From alanb at openjdk.org  Mon Aug  1 15:56:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 15:56:48 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
Message-ID: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>

On Mon, 1 Aug 2022 12:02:19 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?

I think it would be better to split them.

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

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

From bpb at openjdk.org  Mon Aug  1 16:15:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 16:15:59 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
 <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
Message-ID: <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>

On Mon, 1 Aug 2022 06:07:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I think will require a small update to the javadoc to make it clear that both an empty syntax and empty pattern are illegal.

I read the existing specification

     * @throws  IllegalArgumentException
     *          If the parameter does not take the form: {@code syntax:pattern}

as covering both cases, but I suppose one could explicitly state that "neither syntax nor pattern may be empty."

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

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

From aoqi at openjdk.org  Mon Aug  1 16:25:14 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 16:25:14 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v3]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <RVvuKD6GmNvSf0gvQITk2OWA2M_y7UG5IeSRmaeI4uY=.106152b7-0c27-4964-a9fc-f7f3c74eaa21@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  XMLDecoder tests are filed in JDK-8291640

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/623e3723..97c38a36

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

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

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

From aoqi at openjdk.org  Mon Aug  1 16:34:55 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 16:34:55 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations"
In-Reply-To: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
 <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
Message-ID: <51V8ClPS3vEJ9ZwkzJZwiBUTQsJx5XPRLPY_z8IfSxQ=.9d5d5def-5e1d-459a-b0d7-b3e412c546bb@github.com>

On Mon, 1 Aug 2022 15:54:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?
> 
> I think it would be better to split them.

XMLDecoder tests are filed: https://bugs.openjdk.org/browse/JDK-8291640. This issue was also updated.

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

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

From duke at openjdk.org  Mon Aug  1 16:40:20 2022
From: duke at openjdk.org (Bill Huang)
Date: Mon, 1 Aug 2022 16:40:20 GMT
Subject: Integrated: JDK-8289948: Improve test coverage for XPath functions:
 Node Set Functions
In-Reply-To: <WuoYxcHlz66WAM870Xi0MkK81DC0JdQevtopIqt9T7k=.bd493ca3-4ab3-4a04-947e-5c52d0eb5de9@github.com>
References: <WuoYxcHlz66WAM870Xi0MkK81DC0JdQevtopIqt9T7k=.bd493ca3-4ab3-4a04-947e-5c52d0eb5de9@github.com>
Message-ID: <gCbDwrMIInUPlmuGIyTazsJJ9o-5mjsWBvPvjHm7Ia0=.aed7d756-3b23-4098-8c66-46d17c6bf5a4@github.com>

On Mon, 25 Jul 2022 22:04:31 GMT, Bill Huang <duke at openjdk.org> wrote:

> Provided coverage for XPath node set functions. Functions include:
> - id()
> - last()
> - position()
> - count()
> - local-name()
> - namespace-uri()
> - name()

This pull request has now been integrated.

Changeset: 57bf603b
Author:    Bill Huang <bill.w.huang at oracle.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57bf603b7332db86c39680d16b78f94a904daf46
Stats:     354 lines in 4 files changed: 309 ins; 10 del; 35 mod

8289948: Improve test coverage for XPath functions: Node Set Functions

Reviewed-by: joehw

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

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

From hseigel at openjdk.org  Mon Aug  1 16:40:54 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 16:40:54 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
Message-ID: <g-mPywTIxJAAtm2i1MTnf0xKI-IzCHEFcD9YZsHl5dI=.75855ff7-d8dc-4d66-b6cc-6dd152efc13e@github.com>

On Fri, 29 Jul 2022 21:21:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25:
> 
>> 23:  */
>> 24: 
>> 25: // Class with ACC_SUPER set
> 
> Can these classes be defined more succinctly either in Java or .asm?

The jcod test files are relatively small so I don' think they need to be rewritten using asm.

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

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

From naoto at openjdk.org  Mon Aug  1 16:46:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Aug 2022 16:46:01 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <O9yRN6jY9EjtvHp7fHIG81kU_uHr4nFmFs2tviKvJ5k=.a3ff6f40-de36-4f0c-af35-e1adf2c4bf55@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From hseigel at openjdk.org  Mon Aug  1 16:47:51 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 16:47:51 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <E68MNXQqW8adSa0fTRE2r9o-bNy_xy_frcuS3eZ1C34=.d4652e51-69c5-4ce8-b74a-79cb15537447@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
 <rTPgulO7la9xj1mvPFuQ-AFYMAT7CsSUddKJg7t3nfg=.f363ad45-87fd-4f60-be78-7bb76a147be9@github.com>
 <xgwDK4cBoXpn0Vdot8yeldugje7kCuzMTy-eS-hTikY=.397c453e-8720-41ee-8f26-f62ad3ab2e3a@github.com>
 <pX8prnJ_Ag1BhzmY1bKXtB9iE1rXZ32pNKcJR32w2Kc=.384bd443-2644-4b47-a405-18a484a3ccb9@github.com>
 <E68MNXQqW8adSa0fTRE2r9o-bNy_xy_frcuS3eZ1C34=.d4652e51-69c5-4ce8-b74a-79cb15537447@github.com>
Message-ID: <n8yMWX2kO4XinDvSqPQhltZ8k-7eFqjSkB2TM2N3iYM=.b41a87ae-5afd-4bb1-81fd-3782e7e38988@github.com>

On Mon, 1 Aug 2022 14:04:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is.
>
> My companion question was whether the native code can for efficiently map from array class to component type than Java.

I don't know whether Java or the JVM is faster but I would rather keep this code in Java so that I don't have to change existing method JVM_GetClassAccessFlags().  (It's used by Class.getClassAccessFlagsRaw().)

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

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

From rriggs at openjdk.org  Mon Aug  1 17:09:00 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 17:09:00 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v5]
In-Reply-To: <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
Message-ID: <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>

On Thu, 28 Jul 2022 20:43:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 101:

> 99:     PUBLIC(Modifier.PUBLIC, true,
> 100:            Set.of(Location.CLASS, Location.FIELD, Location.METHOD,
> 101:                   Location.INNER_CLASS)) {

Is there another way to implement this that does not create 19 anonymous classes with a single overloaded method?

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

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

From rriggs at openjdk.org  Mon Aug  1 17:10:22 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 17:10:22 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <n8yMWX2kO4XinDvSqPQhltZ8k-7eFqjSkB2TM2N3iYM=.b41a87ae-5afd-4bb1-81fd-3782e7e38988@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
 <rTPgulO7la9xj1mvPFuQ-AFYMAT7CsSUddKJg7t3nfg=.f363ad45-87fd-4f60-be78-7bb76a147be9@github.com>
 <xgwDK4cBoXpn0Vdot8yeldugje7kCuzMTy-eS-hTikY=.397c453e-8720-41ee-8f26-f62ad3ab2e3a@github.com>
 <pX8prnJ_Ag1BhzmY1bKXtB9iE1rXZ32pNKcJR32w2Kc=.384bd443-2644-4b47-a405-18a484a3ccb9@github.com>
 <E68MNXQqW8adSa0fTRE2r9o-bNy_xy_frcuS3eZ1C34=.d4652e51-69c5-4ce8-b74a-79cb15537447@github.com>
 <n8yMWX2kO4XinDvSqPQhltZ8k-7eFqjSkB2TM2N3iYM=.b41a87ae-5afd-4bb1-81fd-3782e7e38988@github.com>
Message-ID: <jPoywlTuX4F1K98biTWUxMPZpFdrCaGWi0mopxGYMNs=.0abd9b2b-810d-4a5c-b41b-5ea4110c52c9@github.com>

On Mon, 1 Aug 2022 16:44:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> My companion question was whether the native code can for efficiently map from array class to component type than Java.
>
> I don't know whether Java or the JVM is faster but I would rather keep this code in Java so that I don't have to change existing method JVM_GetClassAccessFlags().  (It's used by Class.getClassAccessFlagsRaw().)

Makes sense, re-using the existing method.

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

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

From rriggs at openjdk.org  Mon Aug  1 17:10:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 17:10:24 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information
In-Reply-To: <g-mPywTIxJAAtm2i1MTnf0xKI-IzCHEFcD9YZsHl5dI=.75855ff7-d8dc-4d66-b6cc-6dd152efc13e@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
 <g-mPywTIxJAAtm2i1MTnf0xKI-IzCHEFcD9YZsHl5dI=.75855ff7-d8dc-4d66-b6cc-6dd152efc13e@github.com>
Message-ID: <VQtWtxMpVGZCR_0xEHnr5x4gKYqbmDzRxVNuJ4fzAFI=.c5e6c71c-6a96-4acd-bb8e-ffb0ca02ff2f@github.com>

On Mon, 1 Aug 2022 16:38:48 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25:
>> 
>>> 23:  */
>>> 24: 
>>> 25: // Class with ACC_SUPER set
>> 
>> Can these classes be defined more succinctly either in Java or .asm?
>
> The jcod test files are relatively small so I don' think they need to be rewritten using asm.

ok, It mostly knowing which few of the lines are relevant to the test vs. just boilerplate to make a complete class.

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

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

From alanb at openjdk.org  Mon Aug  1 17:19:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 17:19:06 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
 <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
 <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>
Message-ID: <knV-uC-ViKYQajHJGjzlE9DRNNADoLAUOi9vnx1ftlY=.6613c70c-25ba-4c70-86a8-7f60dc73ca66@github.com>

On Mon, 1 Aug 2022 16:13:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I read the existing specification
> 
> ```
>      * @throws  IllegalArgumentException
>      *          If the parameter does not take the form: {@code syntax:pattern}
> ```
> 
> as covering both cases, but I suppose one could explicitly state that "neither syntax nor pattern may be empty."

Alternatively, change "where ':' stands for itself" to "where syntax and pattern components are non-empty strings and ':' stands for itself" sot that it's up front when the input string is described.

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

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

From bpb at openjdk.org  Mon Aug  1 17:19:09 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 17:19:09 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
Message-ID: <8Mo9GDD-j9gFIOBv5hP7X1vkofvh5AztqHGi6_2ljpQ=.10937ed6-9668-4678-be9d-626f02108678@github.com>

On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove IAE message in JrtFileSystem.getPathMatcher()

> Alternatively, change "where ':' stands for itself" to "where syntax and pattern components are non-empty strings and ':' stands for itself" so that it's up front when the input string is described.

I think that reads better; will change accordingly.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:40 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:40 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
Message-ID: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>

I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.

Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.

Before

Benchmark                               Mode  Cnt       Score      Error  Units
StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op


After

Benchmark                               Mode  Cnt       Score      Error  Units
StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

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

Commit messages:
 - Precompute StackTraceElement toString length
 - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
 - Optimize StackTraceElement.toString()
 - Add StackTraceElementBench

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

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

From duke at openjdk.org  Mon Aug  1 17:31:42 2022
From: duke at openjdk.org (Carter Kozak)
Date: Mon, 1 Aug 2022 17:31:42 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <rtBwOiDO-Ln0FgJ4Qab8ewCka-B15ytyBachK2GorDw=.6d60fbb9-d7fc-4c56-be24-a524e9727dda@github.com>

On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <duke at openjdk.org> wrote:

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

I think there's another angle to consider here:
This wasn't an issue using java 8 and earlier because the data encapsulated by StackTraceElement was available using the public API, this meant that logging frameworks were free to implement custom formatters that could be used in place of the toString implementation without losing features and optimizing for niche use-cases (e.g. allocation avoidance).
In recent java versions, the StackTraceElement string value is based on data that's not available using the public API (whether the classloader is builtin, and whether the module is from java.base). String matching can get around this at a potential correctness cost.

It would be helpful for my uses if the new internal attributes were exposed in some way from StackTraceElement, however I understand why that isn't desirable from an API design standpoint.
I suspect a public `appendTo(Appendable)` is a more feasible API addition as it encapsulates the functionality without awareness of what a builtin classloader is, and roughly matches prior art within `Throwable.printStackTrace`. I'd love to get an opinion from someone more closely involved with openjdk core-libs development :-)

src/java.base/share/classes/java/lang/StackTraceElement.java line 374:

> 372:      * @throws IOException If an I/O error occurs
> 373:      */
> 374:     private void appendTo(Appendable dest) throws IOException {

Perhaps this could be package-private for reuse by `Throwable.printStackTrace`, avoiding the intermediate toString.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:43 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Mon, 1 Aug 2022 17:31:43 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <_wTSGZTOaHqY3KolGVN3s-u-NwIQLHxCZU0tuayAt8I=.4cc2f4e2-9c39-432e-a8f4-b1df52d4dd8e@github.com>

On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <duke at openjdk.org> wrote:

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

If the objective of this patch is to optimise `StackTraceElement::toString()`, then I would suggest the most efficient method of calculating the length and encoding of the result, filling the backing buffer then using the package-private constructor of `java.lang.String` to construct the final result.

And if you want to propose exposing `StackTraceElement::appendTo(Appendable)`, then I think it should be a separate patch instead.

Thanks.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:43 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:43 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <_wTSGZTOaHqY3KolGVN3s-u-NwIQLHxCZU0tuayAt8I=.4cc2f4e2-9c39-432e-a8f4-b1df52d4dd8e@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <_wTSGZTOaHqY3KolGVN3s-u-NwIQLHxCZU0tuayAt8I=.4cc2f4e2-9c39-432e-a8f4-b1df52d4dd8e@github.com>
Message-ID: <u0rc_qjjTY9qGFJiMfId1KxYNAMFgvlzBoYhas2JdFQ=.b833fd80-7326-4415-845b-dd2a5b72e9db@github.com>

On Thu, 28 Jul 2022 15:42:15 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> If the objective of this patch is to optimise `StackTraceElement::toString()`, then I would suggest the most efficient method of calculating the length and encoding of the result, filling the backing buffer then using the package-private constructor of `java.lang.String` to construct the final result.
> 
> And if you want to propose exposing `StackTraceElement::appendTo(Appendable)`, then I think it should be a separate patch instead.
> 
> Thanks.

Thanks for the reviews and comments! To @merykitty 's point, I am now focusing this PR on optimizing `StackTraceElement.toString()` only -- additional changes can follow on in subsequent PRs.

I tested out a couple alternative implementations, and have currently landed on precomputing the StringBuilder capacity as seen in current state of this PR (commit https://github.com/openjdk/jdk/pull/9665/commits/aca442839c82688566d94cb5cb43e34b5b029642 ). This shaves a bit more off the `StackTraceElementBench.toString` microbenchmark compared to not precomputing the StringBuilder capacity. The trade off is more readability and more complex code as there are 2 passes -- one to precompute length and one to build the resulting String.

Benchmark                               Mode  Cnt       Score     Error  Units
StackTraceElementBench.printStackTrace  avgt   15  143218.862 ? 840.141  ns/op
StackTraceElementBench.toString         avgt   15      66.566 ?   0.288  ns/op


Alternately, I computed the length and collected into a `char[]` then converted to String as seen in commit https://github.com/openjdk/jdk/commit/de0a337e7f18f9a1525ec222ca22ced93166bf2e . This ends up similar to the presized StringBuilder, with even more complex code, so doesn't seem worth going that route. 

Benchmark                               Mode  Cnt       Score      Error  Units
StackTraceElementBench.printStackTrace  avgt   15  133324.365 ? 1133.849  ns/op
StackTraceElementBench.toString         avgt   15      68.701 ?    1.574  ns/op


I did not write up an implementation to buffer & encode to a `byte[]` and create a resulting string from that via the String constructors or `newStringUTF8NoRepl`. I'm not sure that paying the complexity of UTF-16 handling directly would be worth improvement removing the `char[]` -> `byte[]` conversion & copy, especially in most common case of Latin 1 `StackTraceElement` contents.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:44 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 17:31:44 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <u0rc_qjjTY9qGFJiMfId1KxYNAMFgvlzBoYhas2JdFQ=.b833fd80-7326-4415-845b-dd2a5b72e9db@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <_wTSGZTOaHqY3KolGVN3s-u-NwIQLHxCZU0tuayAt8I=.4cc2f4e2-9c39-432e-a8f4-b1df52d4dd8e@github.com>
 <u0rc_qjjTY9qGFJiMfId1KxYNAMFgvlzBoYhas2JdFQ=.b833fd80-7326-4415-845b-dd2a5b72e9db@github.com>
Message-ID: <lvywW1C0WrfU1RrwGqCKp-RRBOFC9l3XbQ0S8AHBwFM=.9175ab02-0acc-4fa6-92f8-97a70b103cfd@github.com>

On Mon, 1 Aug 2022 16:20:25 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> If the objective of this patch is to optimise `StackTraceElement::toString()`, then I would suggest the most efficient method of calculating the length and encoding of the result, filling the backing buffer then using the package-private constructor of `java.lang.String` to construct the final result.
>> 
>> And if you want to propose exposing `StackTraceElement::appendTo(Appendable)`, then I think it should be a separate patch instead.
>> 
>> Thanks.
>
> Thanks for the reviews and comments! To @merykitty 's point, I am now focusing this PR on optimizing `StackTraceElement.toString()` only -- additional changes can follow on in subsequent PRs.
> 
> I tested out a couple alternative implementations, and have currently landed on precomputing the StringBuilder capacity as seen in current state of this PR (commit https://github.com/openjdk/jdk/pull/9665/commits/aca442839c82688566d94cb5cb43e34b5b029642 ). This shaves a bit more off the `StackTraceElementBench.toString` microbenchmark compared to not precomputing the StringBuilder capacity. The trade off is more readability and more complex code as there are 2 passes -- one to precompute length and one to build the resulting String.
> 
> Benchmark                               Mode  Cnt       Score     Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  143218.862 ? 840.141  ns/op
> StackTraceElementBench.toString         avgt   15      66.566 ?   0.288  ns/op
> 
> 
> Alternately, I computed the length and collected into a `char[]` then converted to String as seen in commit https://github.com/openjdk/jdk/commit/de0a337e7f18f9a1525ec222ca22ced93166bf2e . This ends up similar to the presized StringBuilder, with even more complex code, so doesn't seem worth going that route. 
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  133324.365 ? 1133.849  ns/op
> StackTraceElementBench.toString         avgt   15      68.701 ?    1.574  ns/op
> 
> 
> I did not write up an implementation to buffer & encode to a `byte[]` and create a resulting string from that via the String constructors or `newStringUTF8NoRepl`. I'm not sure that paying the complexity of UTF-16 handling directly would be worth improvement removing the `char[]` -> `byte[]` conversion & copy, especially in most common case of Latin 1 `StackTraceElement` contents.

@schlosna I've filed https://bugs.openjdk.org/browse/JDK-8291641 for this. Please use id `8291641` and rename the ticket to `8291641: Optimize StackTraceElement.toString()`

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

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

From duke at openjdk.org  Mon Aug  1 17:31:47 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 17:31:47 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>

On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <duke at openjdk.org> wrote:

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

src/java.base/share/classes/java/lang/StackTraceElement.java line 366:

> 364:         if (!dropClassLoaderName() && classLoaderName != null && !classLoaderName.isEmpty()) {
> 365:             prefixClassLoader = true;
> 366:             length += classLoaderName.length() + 1 /* '/' */;

Do we still need this comment `/* '/' */`?

src/java.base/share/classes/java/lang/StackTraceElement.java line 400:

> 398:                 dest.append(fileName)
> 399:                         .append(':')
> 400:                         .append(Integer.toString(lineNumber))

I think `Integer.toString(lineNumber)` is redundant here, you can pass `int` directly

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

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

From duke at openjdk.org  Mon Aug  1 17:31:48 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:48 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
Message-ID: <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>

On Mon, 1 Aug 2022 17:08:12 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 366:
> 
>> 364:         if (!dropClassLoaderName() && classLoaderName != null && !classLoaderName.isEmpty()) {
>> 365:             prefixClassLoader = true;
>> 366:             length += classLoaderName.length() + 1 /* '/' */;
> 
> Do we still need this comment `/* '/' */`?

happy to remove these if desired

> src/java.base/share/classes/java/lang/StackTraceElement.java line 400:
> 
>> 398:                 dest.append(fileName)
>> 399:                         .append(':')
>> 400:                         .append(Integer.toString(lineNumber))
> 
> I think `Integer.toString(lineNumber)` is redundant here, you can pass `int` directly

`Appendable` does not currently have an `append(int)` method on the interface, though `StringBuilder` does. We could add it to `Appendable` via default method if so desired:


default Appendable append(int value) {
    return append(Integer.toString(value));
}

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

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

From duke at openjdk.org  Mon Aug  1 17:31:49 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:49 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <rtBwOiDO-Ln0FgJ4Qab8ewCka-B15ytyBachK2GorDw=.6d60fbb9-d7fc-4c56-be24-a524e9727dda@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <rtBwOiDO-Ln0FgJ4Qab8ewCka-B15ytyBachK2GorDw=.6d60fbb9-d7fc-4c56-be24-a524e9727dda@github.com>
Message-ID: <PDuz4Euf-zY7GpNahzwOMXjoeeZOsyRPds5n6kKWxRE=.5825b580-6737-494c-8a07-64c928932f3a@github.com>

On Thu, 28 Jul 2022 00:48:32 GMT, Carter Kozak <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 374:
> 
>> 372:      * @throws IOException If an I/O error occurs
>> 373:      */
>> 374:     private void appendTo(Appendable dest) throws IOException {
> 
> Perhaps this could be package-private for reuse by `Throwable.printStackTrace`, avoiding the intermediate toString.

Yes, I think the `PrintStreamOrWriter` could implement `Appendable` as both `PrintStream` and `PrintWriter` implement `Appendable`. 

https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L756

This would also potentially allow optimizing away the additional intermediate strings from prefixing the lines with `"\tat "` concatenated with the `StackTraceElement.toString()`

https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L686-L687

https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L724-L725

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

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

From duke at openjdk.org  Mon Aug  1 17:31:50 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:50 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <PDuz4Euf-zY7GpNahzwOMXjoeeZOsyRPds5n6kKWxRE=.5825b580-6737-494c-8a07-64c928932f3a@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <rtBwOiDO-Ln0FgJ4Qab8ewCka-B15ytyBachK2GorDw=.6d60fbb9-d7fc-4c56-be24-a524e9727dda@github.com>
 <PDuz4Euf-zY7GpNahzwOMXjoeeZOsyRPds5n6kKWxRE=.5825b580-6737-494c-8a07-64c928932f3a@github.com>
Message-ID: <8tDBKTb7FEh3o5IsmYHwi4Br6UGGa9qymxJrjju9-uw=.cfa076bb-dfd5-4bd2-a1ac-8c721ab6210d@github.com>

On Thu, 28 Jul 2022 01:23:53 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackTraceElement.java line 374:
>> 
>>> 372:      * @throws IOException If an I/O error occurs
>>> 373:      */
>>> 374:     private void appendTo(Appendable dest) throws IOException {
>> 
>> Perhaps this could be package-private for reuse by `Throwable.printStackTrace`, avoiding the intermediate toString.
>
> Yes, I think the `PrintStreamOrWriter` could implement `Appendable` as both `PrintStream` and `PrintWriter` implement `Appendable`. 
> 
> https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L756
> 
> This would also potentially allow optimizing away the additional intermediate strings from prefixing the lines with `"\tat "` concatenated with the `StackTraceElement.toString()`
> 
> https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L686-L687
> 
> https://github.com/openjdk/jdk/blob/348a0521e1cd602c4093955310f838cf4ce4daae/src/java.base/share/classes/java/lang/Throwable.java#L724-L725

Just making notes for the future: having `PrintStreamOrWriter implement Appendable` works, but slightly messy due to `append` methods throwing checked `IOException` so these would likely need to catch & ignore. Given `Throwable.printStackTrace` is typically on an error handling path, if the `PrintStreamOrWriter` error stream/writer is not functioning properly, I imagine one would want to know but may be prevented from knowing.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:52 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 17:31:52 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
Message-ID: <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>

On Thu, 28 Jul 2022 13:07:01 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackTraceElement.java line 400:
>> 
>>> 398:                 dest.append(fileName)
>>> 399:                         .append(':')
>>> 400:                         .append(Integer.toString(lineNumber))
>> 
>> I think `Integer.toString(lineNumber)` is redundant here, you can pass `int` directly
>
> `Appendable` does not currently have an `append(int)` method on the interface, though `StringBuilder` does. We could add it to `Appendable` via default method if so desired:
> 
> 
> default Appendable append(int value) {
>     return append(Integer.toString(value));
> }

I think in this case it's better to specify `StringBuilder` instead of `Appendable`, because the method is private and you'd hardly ever pass there anything different from SB.

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

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

From duke at openjdk.org  Mon Aug  1 17:31:53 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:31:53 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
 <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>
Message-ID: <bvsJQ_N7G0Eu_Lg2B1uI593WHwjarekC8qaj4qU2L3s=.42433a00-03b5-466a-b21a-ba731234005c@github.com>

On Thu, 28 Jul 2022 13:12:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> `Appendable` does not currently have an `append(int)` method on the interface, though `StringBuilder` does. We could add it to `Appendable` via default method if so desired:
>> 
>> 
>> default Appendable append(int value) {
>>     return append(Integer.toString(value));
>> }
>
> I think in this case it's better to specify `StringBuilder` instead of `Appendable`, because the method is private and you'd hardly ever pass there anything different from SB.

If we go with the proposal above to make `appendTo(Appendable)` package visible so that `Throwable.printStackTrace()` can benefit from this as well, we would need to keep this as Appendable, otherwise I agree we should just inline this all into toString

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

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

From duke at openjdk.org  Mon Aug  1 17:31:54 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 17:31:54 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <bvsJQ_N7G0Eu_Lg2B1uI593WHwjarekC8qaj4qU2L3s=.42433a00-03b5-466a-b21a-ba731234005c@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
 <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>
 <bvsJQ_N7G0Eu_Lg2B1uI593WHwjarekC8qaj4qU2L3s=.42433a00-03b5-466a-b21a-ba731234005c@github.com>
Message-ID: <LsDicTOP2JN-yeG0vSlsNWAtTv1bTm-b53LMAbbySug=.c8ce2b38-cbb9-45e3-8d66-77534c592690@github.com>

On Thu, 28 Jul 2022 13:45:53 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I think in this case it's better to specify `StringBuilder` instead of `Appendable`, because the method is private and you'd hardly ever pass there anything different from SB.
>
> If we go with the proposal above to make `appendTo(Appendable)` package visible so that `Throwable.printStackTrace()` can benefit from this as well, we would need to keep this as Appendable, otherwise I agree we should just inline this all into toString

`Throwable.printStackTrace()` will use `StringBuilder` as well, won't it?

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

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

From duke at openjdk.org  Mon Aug  1 17:31:55 2022
From: duke at openjdk.org (Carter Kozak)
Date: Mon, 1 Aug 2022 17:31:55 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <LsDicTOP2JN-yeG0vSlsNWAtTv1bTm-b53LMAbbySug=.c8ce2b38-cbb9-45e3-8d66-77534c592690@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
 <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>
 <bvsJQ_N7G0Eu_Lg2B1uI593WHwjarekC8qaj4qU2L3s=.42433a00-03b5-466a-b21a-ba731234005c@github.com>
 <LsDicTOP2JN-yeG0vSlsNWAtTv1bTm-b53LMAbbySug=.c8ce2b38-cbb9-45e3-8d66-77534c592690@github.com>
Message-ID: <naa6aNgi6H5GVS7Rhpze1GZfOFz4gwTS9xEKUsHGwWU=.fbba6c39-cea6-4c7e-9f17-b67d1728a5ad@github.com>

On Thu, 28 Jul 2022 14:33:39 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> If we go with the proposal above to make `appendTo(Appendable)` package visible so that `Throwable.printStackTrace()` can benefit from this as well, we would need to keep this as Appendable, otherwise I agree we should just inline this all into toString
>
> `Throwable.printStackTrace()` will use `StringBuilder` as well, won't it?

I don't think so, it appends directly do something like System.err (default) or another PrintStream/PrintWriter without fully holding the string value on heap. If it supported overloads for Appendable/StringBuilder, that would be fantastic, but that would expand the scope of this PR. Is that something you would support?

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

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

From duke at openjdk.org  Mon Aug  1 17:31:56 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 17:31:56 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <naa6aNgi6H5GVS7Rhpze1GZfOFz4gwTS9xEKUsHGwWU=.fbba6c39-cea6-4c7e-9f17-b67d1728a5ad@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
 <eczNmrsoDtxG3h1qzzZfA2Z9wTIpFthu0NabDGeMghs=.0b193f6d-f12b-48f2-9cd8-fb9fb08c5dc3@github.com>
 <bvsJQ_N7G0Eu_Lg2B1uI593WHwjarekC8qaj4qU2L3s=.42433a00-03b5-466a-b21a-ba731234005c@github.com>
 <LsDicTOP2JN-yeG0vSlsNWAtTv1bTm-b53LMAbbySug=.c8ce2b38-cbb9-45e3-8d66-77534c592690@github.com>
 <naa6aNgi6H5GVS7Rhpze1GZfOFz4gwTS9xEKUsHGwWU=.fbba6c39-cea6-4c7e-9f17-b67d1728a5ad@github.com>
Message-ID: <sxo_RWPS_KqnExrnxkJjQu2xsmbtfiA3YJNlWj7ZOmg=.f8c57ba8-987f-4c01-b80f-e01fd91e0cb5@github.com>

On Thu, 28 Jul 2022 14:38:50 GMT, Carter Kozak <duke at openjdk.org> wrote:

>> `Throwable.printStackTrace()` will use `StringBuilder` as well, won't it?
>
> I don't think so, it appends directly do something like System.err (default) or another PrintStream/PrintWriter without fully holding the string value on heap. If it supported overloads for Appendable/StringBuilder, that would be fantastic, but that would expand the scope of this PR. Is that something you would support?

I think we could create another PR adding suggested 

default Appendable append(int value) {
    return append(Integer.toString(value));
}

to `Appendable` if other JDK developers find it reasonable. Otherwise let's keep it as is.

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

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

From duke at openjdk.org  Mon Aug  1 17:35:05 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:35:05 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v2]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/aca44283..e7d26aca

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

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

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

From rriggs at openjdk.org  Mon Aug  1 17:35:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 17:35:51 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
Message-ID: <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>

On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove IAE message in JrtFileSystem.getPathMatcher()

> 

The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string.
If I read it correctly, it will now throw an exception instead of not matching.  It might be safer to not change that behavior.

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

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

From duke at openjdk.org  Mon Aug  1 17:41:07 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 1 Aug 2022 17:41:07 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v5]
In-Reply-To: <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
 <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>
Message-ID: <tUX-ZrLZol14PoteIR8om0IyuwCi7ZrjBJenooAA-8A=.dc29430a-5a8b-4b09-91e6-990b5d4d33da@github.com>

On Mon, 1 Aug 2022 17:04:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Appease jcheck.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 101:
> 
>> 99:     PUBLIC(Modifier.PUBLIC, true,
>> 100:            Set.of(Location.CLASS, Location.FIELD, Location.METHOD,
>> 101:                   Location.INNER_CLASS)) {
> 
> Is there another way to implement this that does not create 19 anonymous classes with a single overloaded method?

Probably?by?creating and?using shared?instances of?`java.util.Function` which?would also?allow deduplicating?the?code.

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

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

From duke at openjdk.org  Mon Aug  1 17:42:50 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Aug 2022 17:42:50 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v2]
In-Reply-To: <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <MRcZOL4Go46GLesGQ3EpMKzAOnG2it6QNa3UKTFIdkw=.06e9c845-e200-4f84-b4d8-c22f9d23da37@github.com>
 <1BBQ3ldNS_O39zHRAw5MKTZAt2tqrWVAfDDbNRKLdVg=.106e23af-67ee-4d92-b8f9-1f725f2c0443@github.com>
Message-ID: <3_iPPKsmNOSkRpN41m1XxV_YoKcMV-UDhy5JNm0IRq4=.cfb7a38a-7d81-4281-a756-5aced9fa4e01@github.com>

On Mon, 1 Aug 2022 17:24:48 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackTraceElement.java line 366:
>> 
>>> 364:         if (!dropClassLoaderName() && classLoaderName != null && !classLoaderName.isEmpty()) {
>>> 365:             prefixClassLoader = true;
>>> 366:             length += classLoaderName.length() + 1 /* '/' */;
>> 
>> Do we still need this comment `/* '/' */`?
>
> happy to remove these if desired

updated to remove extraneous comments

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

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

From hseigel at openjdk.org  Mon Aug  1 18:51:10 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 18:51:10 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
Message-ID: <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>

> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
> 
> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9688/files
  - new: https://git.openjdk.org/jdk/pull/9688/files/2f5d1468..82890e56

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

  Stats: 55 lines in 5 files changed: 27 ins; 10 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9688.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688

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

From duke at openjdk.org  Mon Aug  1 18:56:52 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 1 Aug 2022 18:56:52 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v2]
In-Reply-To: <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>
Message-ID: <QSfwwFntT90jdFfdTTb5gu7DB_KRZmqjuQgjONsttKo=.587b7997-1b5b-48e7-84c0-66b7432fd713@github.com>

On Mon, 1 Aug 2022 17:35:05 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

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

From hseigel at openjdk.org  Mon Aug  1 18:57:19 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 18:57:19 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
Message-ID: <-qL5Q9n31S1en7zXqUUHSepr8rNcX22XEXHgC9Xb3X0=.3e7b0376-3b83-4bf7-9051-53d709f698c9@github.com>

On Mon, 1 Aug 2022 18:51:10 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's

Thanks Brian, Roger, and David for looking at this.  I pushed a new commit to address the review comments, add mulit-dimensional array test cases, and simplify new java.lang.Class API's.

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

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

From hseigel at openjdk.org  Mon Aug  1 18:57:21 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 18:57:21 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
Message-ID: <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>

On Sun, 31 Jul 2022 22:02:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's
>
> src/hotspot/share/include/jvm.h line 1163:
> 
>> 1161: 
>> 1162: /*
>> 1163:  * Value types support.
> 
> Value types? This is supporting the core reflection work isn't it?

I fixed this in the second commit.

> src/hotspot/share/prims/jvm.cpp line 4050:
> 
>> 4048: /*
>> 4049:  * Return the current class's class file version.  The low order 16 bits of the
>> 4050:  * the returned jint contains the class's major version.  The high order 16 bits
> 
> typo "the the" across the lines
> typo s/contains/contain/

Fixed!

> src/hotspot/share/prims/jvm.cpp line 4051:
> 
>> 4049:  * Return the current class's class file version.  The low order 16 bits of the
>> 4050:  * the returned jint contains the class's major version.  The high order 16 bits
>> 4051:  * contains the class's minor version.
> 
> typo s/contains/contain/

Fixed.

> test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 66:
> 
>> 64:         flags = (int)m.invoke((new SUPERnotset[2]).getClass());
>> 65:         if (flags != 1) {
>> 66:             throw new RuntimeException("expected 1, got " + flags + " for object array");
> 
> Again hex output would be clearer

Changed this in the second commit to display hex outout.

> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45:
> 
>> 43:         if (ver != expectedResult) {
>> 44:             throw new RuntimeException(
>> 45:                 "expected " + expectedResult + ", got " + ver + " for class " + className);
> 
> It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong.

Changed to display as major:minor version.

> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 62:
> 
>> 60:         int ver = (int)m.invoke((new int[3]).getClass());
>> 61:         if (ver != 64) {
>> 62:             throw new RuntimeException("expected 64, got " + ver + " for primitive array");
> 
> Again minor:major format.

Changed to display as major:minor version.

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

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

From hseigel at openjdk.org  Mon Aug  1 18:57:22 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Mon, 1 Aug 2022 18:57:22 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <KMX-FU-nEjE4rs7ryG3go3xvYqxszvDqfrAOALQX7xQ=.69dfb440-d701-4d3d-8439-ac95e157de63@github.com>
Message-ID: <DA3XNKtub-_iSlQPppBH0guLW57Cnzw92AFyLcPY_fk=.34cd3f60-8843-4842-9c90-3e6adbd3883f@github.com>

On Fri, 29 Jul 2022 21:08:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's
>
> test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 59:
> 
>> 57:         // test primitive array.  should return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC.
>> 58:         int flags = (int)m.invoke((new int[3]).getClass());
>> 59:         if (flags != 1041) {
> 
> Can this be a hex constant, It's easier to understand the bits.
> Or assemble the flags from java.lang.reflect.Modifier.XXX static fields.

I changed this in the second commit to use java.lang.reflect.Modifier static fields.

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

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

From bpb at openjdk.org  Mon Aug  1 20:03:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 20:03:14 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
Message-ID: <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>

On Mon, 1 Aug 2022 17:32:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string. If I read it correctly, it will now throw an exception instead of not matching. It might be safer to not change that behavior.

Indeed for this code

        FileSystem fs = ...;
        PathMatcher pm = fs.getPathMatcher("glob:");
        System.out.println(pm.matches(Path.of("")));

without the proposed change `true` is printed but with the change an `IllegalArgumentException` is thrown so it would be safer to change

        if (pos <= 0 || pos == syntaxAndInput.length())

to

        if (pos <= 0)

as originally suggested.

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

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

From naoto at openjdk.org  Mon Aug  1 21:11:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Aug 2022 21:11:48 GMT
Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content
 [v6]
In-Reply-To: <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
Message-ID: <Tgy4speKY6VBTUWMIAvdTMYv2IEx8XmkKKgvbNqZEgk=.9f4c26da-57ad-421e-ab3e-fed56e4d1581@github.com>

On Sat, 30 Jul 2022 20:52:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `assertThrows`

Looks like it is not much of an additional benefit without APIs. Decided not to implement it at this time.

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

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

From duke at openjdk.org  Mon Aug  1 21:33:19 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Mon, 1 Aug 2022 21:33:19 GMT
Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content
 [v6]
In-Reply-To: <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
Message-ID: <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>

On Sat, 30 Jul 2022 20:52:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `assertThrows`

lgtm

hi! by the way if you want to see some more `-t-` names in the wild, I recently merged https://github.com/unicode-org/cldr/pull/1755

test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 80:

> 78:         return new Object[][] {
> 79:                 {L1, Locale.US,
> 80:                         "Cyrillic (Transform: Latin, Transform Rules: UN GEGN Transliteration 2007)"},

? I like these display names!

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

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

From duke at openjdk.org  Mon Aug  1 21:33:19 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Mon, 1 Aug 2022 21:33:19 GMT
Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content
 [v6]
In-Reply-To: <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
 <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>
Message-ID: <ZxQDyKQJf3OkCrAx1dPPfcRKm3x6RUF6k7I78Vxs_iU=.c8d2ae70-3530-418c-8a15-5dd85e06d4e1@github.com>

On Mon, 1 Aug 2022 21:27:47 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use `assertThrows`
>
> test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 80:
> 
>> 78:         return new Object[][] {
>> 79:                 {L1, Locale.US,
>> 80:                         "Cyrillic (Transform: Latin, Transform Rules: UN GEGN Transliteration 2007)"},
> 
> ? I like these display names!

Note: another class of use for `-t-` is for keyboards, so for example `ar-t-k0-windows-azerty` in https://github.com/unicode-org/cldr/blob/release-41/keyboards/windows/ar-t-k0-windows-azerty.xml

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

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

From duke at openjdk.org  Mon Aug  1 22:29:46 2022
From: duke at openjdk.org (Neustradamus)
Date: Mon, 1 Aug 2022 22:29:46 GMT
Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
 [v2]
In-Reply-To: <roPNy0sXc91vmvFgFcaARGcIMExpfyrpsoCqn0DQKcQ=.0e75309f-5ba7-49d8-a460-513419b1ca5a@github.com>
References: <bVEPJ-DqPlYTcySdmgVi1CWpRu7uZOTEl7SS0ytv350=.5668cfee-ce06-46f9-b2a8-9eafa53892eb@github.com>
 <roPNy0sXc91vmvFgFcaARGcIMExpfyrpsoCqn0DQKcQ=.0e75309f-5ba7-49d8-a460-513419b1ca5a@github.com>
Message-ID: <eKYJjSC4MXZPAgsQgAmtuL6zend34NVW0yob1uLv628=.68e05d86-fcb1-419d-b69b-ff60d6f277ea@github.com>

On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hi,
>> 
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos.
>> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
>> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point"
>> 
>> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>> 
>> Thank you
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8245527: version.01

@alexeybakhtin: It is official for TLS 1.3 Binding!
- RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

Details:
- tls-unique for TLS =< 1.2
- tls-exporter for TLS = 1.3

Can you look to add it?

Thanks in advance.

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

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

From prr at openjdk.org  Mon Aug  1 22:52:52 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:52:52 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RzARYHG0jJJZm-EExZ4T_eITO9lJTQXAJWi9vidinjA=.2b597369-2406-43ad-a611-5d8eb8860193@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Looks fine to me. However the langtools / javadoc folks seem like they should be primary reviewers since it is mostly messages from the tools.

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

Marked as reviewed by prr (Reviewer).

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

From darcy at openjdk.org  Mon Aug  1 23:12:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 1 Aug 2022 23:12:11 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v5]
In-Reply-To: <tUX-ZrLZol14PoteIR8om0IyuwCi7ZrjBJenooAA-8A=.dc29430a-5a8b-4b09-91e6-990b5d4d33da@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
 <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>
 <tUX-ZrLZol14PoteIR8om0IyuwCi7ZrjBJenooAA-8A=.dc29430a-5a8b-4b09-91e6-990b5d4d33da@github.com>
Message-ID: <tbhhHvHT62PIqglDmGIg2RyA6Kq8wl7-p1CqF9qGq2Q=.91e062b9-1887-4184-8967-35b2d0d61773@github.com>

On Mon, 1 Aug 2022 17:37:36 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 101:
>> 
>>> 99:     PUBLIC(Modifier.PUBLIC, true,
>>> 100:            Set.of(Location.CLASS, Location.FIELD, Location.METHOD,
>>> 101:                   Location.INNER_CLASS)) {
>> 
>> Is there another way to implement this that does not create 19 anonymous classes with a single overloaded method?
>
> Probably?by?creating and?using shared?instances of?`java.util.Function` which?would also?allow deduplicating?the?code.

> Is there another way to implement this that does not create 19 anonymous classes with a single overloaded method?

Overriding a method in an enum constant specific class is one way to implement constant-specific behavior. Textually, I thought it had the advantage of having the class file version specific behavior close to the latest version behavior.

This could be refactored in various ways, such as having AccessFlag.locations(ClassFileFormatVersion cffv) start with a switch over the location which implemented the enum constant specific behavior. Or the set of parameters of the enum constructor could be augmented to cover more cases (empty until $VERSION, then $LOCATIONS, etc.), with constant-specific overrides just constants with unique patterns like STRICT.

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

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

From smarks at openjdk.org  Mon Aug  1 23:37:14 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 1 Aug 2022 23:37:14 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <kIpLeARjT24eijuUZiWzNsiW_3pLTlW5R9TovRMGdbk=.d30075a8-ca01-428b-8886-6ecba1468a70@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach 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:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

No action needed from you at this time. This is mostly waiting for me to get some time to focus on this. Thanks for your patience.

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

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

From duke at openjdk.org  Tue Aug  2 05:32:13 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 2 Aug 2022 05:32:13 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v2]
In-Reply-To: <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>
Message-ID: <sBEBQm1FrzgvufjEpBS-yZkptzTsP7BiUFd_j4rwPjQ=.2674dc24-8627-4663-8934-7c310004a5ab@github.com>

On Mon, 1 Aug 2022 17:35:05 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Since constructing a `String` from a `StringBuilder` requires an array copy anyway, you don't need to be exact in the capacity of the builder and overshooting is fine. This can simplify the length calculation a lot. Thanks.

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

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

From aoqi at openjdk.org  Tue Aug  2 06:32:09 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 2 Aug 2022 06:32:09 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

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

 - Merge branch 'master' into 8291508
 - XMLDecoder tests are filed in JDK-8291640
 - XMLDecoder update
   
   Co-authored-by: Alan Bateman <alanb at openjdk.org>
 - 8291508: Fix some tests with "requires vm.continuations"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/97c38a36..1e00cd83

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

  Stats: 2659 lines in 193 files changed: 1590 ins; 605 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/9677.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677

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

From dholmes at openjdk.org  Tue Aug  2 06:41:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Aug 2022 06:41:24 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
Message-ID: <xo3ZgF1YZ9B2wxJL7OzZaGYDpyZhwO6kL4nPEDSC_xk=.1990c66a-613b-4da1-bdd3-d53ec06977bc@github.com>

On Mon, 1 Aug 2022 18:51:10 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's

src/java.base/share/classes/java/lang/Class.java line 4682:

> 4680:      */
> 4681:     private int getClassFileVersion() {
> 4682:         Class<?> component = isArray() ? elementType() : this;

The variable name `component` seems completely not applicable now. I would just use `c`.

test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 67:

> 65:         if (ver != 64) {
> 66:             int got_minor = (ver >> 16) & 0x0000FFFF;
> 67:             int got_major = ver & 0x0000FFFF;

`got` seems odd in this context as these are not boolean queries.

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

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

From dholmes at openjdk.org  Tue Aug  2 06:41:27 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Aug 2022 06:41:27 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>
Message-ID: <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com>

On Mon, 1 Aug 2022 13:26:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4698:
>> 
>>> 4696:      *
>>> 4697:      * If the class is an array type then the access flags of the component type is
>>> 4698:      * returned.  If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC.
>> 
>> The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice?
>
> I don't know why API's such as JVM_GetClassModifiers() and JVM_GetClassAccessFlags return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC for primitives.  Nor could I find a spec that discussed access flags for primitives.  But, I didn't want to change what's been returned for primitives in existing code.

Interesting. `Class.getModifiers()` does not specify `ACC_ABSTRACT` so this seems to be something implementation specific (although no doubt a long standing situation.)

>> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55:
>> 
>>> 53: 
>>> 54:         testIt("Version64", 64);
>>> 55:         testIt("Version59", 59);
>> 
>> Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions?
>
> No particular reason for choosing 59 other than it's different and less than 64.  Test case Version64_65535 has a non-zero minor version.

I think we should be testing for other real classfile versions that may be encountered, such as 45.3

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

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

From dholmes at openjdk.org  Tue Aug  2 06:51:12 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Aug 2022 06:51:12 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>
Message-ID: <lOcBD83O9CFlfZev-92BsVNhEv3gN7T6CVu7vYma7a0=.4ef61727-d593-456b-aab7-d56f4d52a5ce@github.com>

On Mon, 1 Aug 2022 13:30:21 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 4064:
>> 
>>> 4062:   assert(c->is_instance_klass(), "must be");
>>> 4063:   InstanceKlass* ik = InstanceKlass::cast(c);
>>> 4064:   return (ik->minor_version() << 16) | ik->major_version();
>> 
>> I'm curious why the format is minor:major rather than major:minor ?
>
> This was requested by @RogerRiggs 
> 
> Major high vs low bits requires either:
>   High bits:   val >>>16
>   Low bits:     val & 0xffff
> 
> Except for preview, the minor version is 0, so putting major version  in the low bits allows trivial comparison (without masking); but may lead to bugs due to carelessness.

Okay makes sense.

>> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31:
>> 
>>> 29:  * @modules java.base/java.lang:open
>>> 30:  * @compile classFileVersions.jcod
>>> 31:  * @run main/othervm --enable-preview ClassFileVersionTest
>> 
>> What preview feature is being used here?
>
> No preview feature is being used but --enable-preview is needed here for the JVM to accept a class with a minor version of 65535.

Ah I see.

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

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

From dholmes at openjdk.org  Tue Aug  2 06:54:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Aug 2022 06:54:42 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
Message-ID: <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>

On Mon, 1 Aug 2022 18:51:31 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45:
>> 
>>> 43:         if (ver != expectedResult) {
>>> 44:             throw new RuntimeException(
>>> 45:                 "expected " + expectedResult + ", got " + ver + " for class " + className);
>> 
>> It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong.
>
> Changed to display as major:minor version.

Seems odd to display as major:minor when it is stored as minor:majpor

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

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

From sspitsyn at openjdk.org  Tue Aug  2 06:59:24 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Aug 2022 06:59:24 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <RgSuOV1j5nPaotE4O96x5QU2Ab8R8corK5vCbsHzBXk=.288a6bf5-6d43-4954-8d90-b4cac8e4c5e7@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

I'm surprised these two tests have the `--enable-preview` flag.
@lmesnik Could you, please, take a look at these two tests?
Otherwise, the fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dholmes at openjdk.org  Tue Aug  2 07:03:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Aug 2022 07:03:53 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <xo3ZgF1YZ9B2wxJL7OzZaGYDpyZhwO6kL4nPEDSC_xk=.1990c66a-613b-4da1-bdd3-d53ec06977bc@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
 <xo3ZgF1YZ9B2wxJL7OzZaGYDpyZhwO6kL4nPEDSC_xk=.1990c66a-613b-4da1-bdd3-d53ec06977bc@github.com>
Message-ID: <Wh0Mqoh-lyCAYj8yDrjAozBd2wNL7lcX8Mok4Xr33so=.e43930fc-ebb2-47c1-bb7e-0930d309bc5c@github.com>

On Tue, 2 Aug 2022 06:38:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's
>
> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 67:
> 
>> 65:         if (ver != 64) {
>> 66:             int got_minor = (ver >> 16) & 0x0000FFFF;
>> 67:             int got_major = ver & 0x0000FFFF;
> 
> `got` seems odd in this context as these are not boolean queries.

Sorry I "got" it now :)

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

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

From alanb at openjdk.org  Tue Aug  2 08:39:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 08:39:23 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

test/jdk/java/beans/XMLEncoder/Test4625418.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4625418 8239965 8290488

I'm curious why this XMLEncoder test is updated, is this related to round trip?

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

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

From alanb at openjdk.org  Tue Aug  2 11:58:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 11:58:06 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
 <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
Message-ID: <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>

On Mon, 1 Aug 2022 19:59:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string.
> If I read it correctly, it will now throw an exception instead of not matching. It might be safer to not change that behavior.

I'm 99% sure the original intention was for the empty pattern to be rejected with IAE. It was an implementation but that it checked if the index is length rather than length-1. That was JDK 7 and changing is now without be behavior change. I can't imagine the impact would be significant but I agree it's not worth it and maybe we just drop the check as per the JBS issue and update the spec to document the long standing behavior.

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

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

From hseigel at openjdk.org  Tue Aug  2 12:50:05 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Tue, 2 Aug 2022 12:50:05 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
 <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
Message-ID: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>

On Tue, 2 Aug 2022 06:51:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Changed to display as major:minor version.
>
> Seems odd to display as major:minor when it is stored as minor:major

I think it seems more natural to display the major version first, but I can change it if you prefer.

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

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

From duke at openjdk.org  Tue Aug  2 13:34:26 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 13:34:26 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v3]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <PRkP5eTFyNbCPz3-_o7VK6eL4EY2GLNewfzdE1teHgk=.8b382099-4427-49c4-beee-47c1d026352b@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:

  Estimate length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/e7d26aca..d3774a69

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

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

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

From duke at openjdk.org  Tue Aug  2 13:47:41 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 13:47:41 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v2]
In-Reply-To: <sBEBQm1FrzgvufjEpBS-yZkptzTsP7BiUFd_j4rwPjQ=.2674dc24-8627-4663-8934-7c310004a5ab@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <zLYed5YM5vmfHgVrC6Stitt_rAg0LWF5q45Vkh8P2zY=.3748e261-0190-4c8b-bddb-9b4f79d2a999@github.com>
 <sBEBQm1FrzgvufjEpBS-yZkptzTsP7BiUFd_j4rwPjQ=.2674dc24-8627-4663-8934-7c310004a5ab@github.com>
Message-ID: <7-E1qNM63f4X1R3_QlXLRkyuTe7hwcakj4kLciMZpTQ=.aec0ea3f-6ef5-4fae-9592-7f4890ff1401@github.com>

On Tue, 2 Aug 2022 05:29:38 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> Since constructing a `String` from a `StringBuilder` requires an array copy anyway, you don't need to be exact in the capacity of the builder and overshooting is fine. This can simplify the length calculation a lot. Thanks.

Good call @merykitty , I updated with my take on simplifying the length estimate, let me know if that reads better.

JMH as of https://github.com/openjdk/jdk/pull/9665/commits/d3774a69b1e6f316ff8b4af257fb2e95e5c4c3dd for comparison to previous, so still a ~50% improvement over existing state on my x64 test environment (`Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz`).

Benchmark                               Mode  Cnt       Score     Error  Units
StackTraceElementBench.printStackTrace  avgt   15  144011.319 ? 959.263  ns/op
StackTraceElementBench.toString         avgt   15      67.874 ?   0.485  ns/op

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

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

From duke at openjdk.org  Tue Aug  2 13:55:22 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 2 Aug 2022 13:55:22 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v3]
In-Reply-To: <PRkP5eTFyNbCPz3-_o7VK6eL4EY2GLNewfzdE1teHgk=.8b382099-4427-49c4-beee-47c1d026352b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <PRkP5eTFyNbCPz3-_o7VK6eL4EY2GLNewfzdE1teHgk=.8b382099-4427-49c4-beee-47c1d026352b@github.com>
Message-ID: <2F6XYjZek5CHCRr50Z1V3TSQN5EnykMHsUrT1c-YHos=.0da472af-acc3-4dae-84f4-a1cd8ff6240f@github.com>

On Tue, 2 Aug 2022 13:34:26 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Estimate length

Otherwise looks good to me, thanks

src/java.base/share/classes/java/lang/StackTraceElement.java line 365:

> 363:                 + methodName.length() + 1
> 364:                 + Math.max("Unknown Source".length(), Objects.requireNonNullElse(fileName, "").length()) + 1
> 365:                 + Integer.stringSize(lineNumber) + 1;

`Integer.stringSize(lineNumber)` can be further simplify to `11`

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

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

From duke at openjdk.org  Tue Aug  2 13:57:03 2022
From: duke at openjdk.org (iaroslavski)
Date: Tue, 2 Aug 2022 13:57:03 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v16]
In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
Message-ID: <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>

> 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)
  
  * Optimized and unified buffer allocation
  * Minor comment changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/3938/files
  - new: https://git.openjdk.org/jdk/pull/3938/files/618bdb5f..fcda2aa8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=14-15

  Stats: 140 lines in 1 file changed: 33 ins; 72 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/3938.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938

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

From duke at openjdk.org  Tue Aug  2 13:58:52 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 13:58:52 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v4]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <rCm2H_GtgIp6knv6fcrki-D9b7fsT9CTbx5IszFhXHk=.e2dfe2a8-28ca-44a2-9841-769acaabdc71@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:

  Inline max Integer.stringSize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/d3774a69..bbc683f3

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

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

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

From duke at openjdk.org  Tue Aug  2 14:05:50 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 14:05:50 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v3]
In-Reply-To: <2F6XYjZek5CHCRr50Z1V3TSQN5EnykMHsUrT1c-YHos=.0da472af-acc3-4dae-84f4-a1cd8ff6240f@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <PRkP5eTFyNbCPz3-_o7VK6eL4EY2GLNewfzdE1teHgk=.8b382099-4427-49c4-beee-47c1d026352b@github.com>
 <2F6XYjZek5CHCRr50Z1V3TSQN5EnykMHsUrT1c-YHos=.0da472af-acc3-4dae-84f4-a1cd8ff6240f@github.com>
Message-ID: <ph8ZF3ZNka0j51UEjpzNlYEbdj3s2g4JsZ0fVkHVk9o=.ee3430d4-1ded-4235-a9d5-c4c6f38d3e98@github.com>

On Tue, 2 Aug 2022 13:52:30 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Estimate length
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 365:
> 
>> 363:                 + methodName.length() + 1
>> 364:                 + Math.max("Unknown Source".length(), Objects.requireNonNullElse(fileName, "").length()) + 1
>> 365:                 + Integer.stringSize(lineNumber) + 1;
> 
> `Integer.stringSize(lineNumber)` can be further simplify to `11`

inlined as 12 (combined with `1` for trailing `)`)

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

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

From hseigel at openjdk.org  Tue Aug  2 14:12:44 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Tue, 2 Aug 2022 14:12:44 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v3]
In-Reply-To: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
Message-ID: <ABiK1_0-jf-kY9WF8xpxMhyLjIPcSlwrBw79lVnfHWk=.d2228a62-b85a-409d-b4b8-495fb74fd111@github.com>

> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
> 
> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  add test case, minor renames

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9688/files
  - new: https://git.openjdk.org/jdk/pull/9688/files/82890e56..941971dc

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

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

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

From hseigel at openjdk.org  Tue Aug  2 14:12:46 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Tue, 2 Aug 2022 14:12:46 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v2]
In-Reply-To: <xo3ZgF1YZ9B2wxJL7OzZaGYDpyZhwO6kL4nPEDSC_xk=.1990c66a-613b-4da1-bdd3-d53ec06977bc@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <BLseQOKYDJDC0MHXaK5NbcP9jtV3bu7_1rXyAARDveI=.fcbcca70-08cf-42d8-9568-087d31935613@github.com>
 <xo3ZgF1YZ9B2wxJL7OzZaGYDpyZhwO6kL4nPEDSC_xk=.1990c66a-613b-4da1-bdd3-d53ec06977bc@github.com>
Message-ID: <8_Jv1YwCxG5wGqtticVYokITBBJURYX0F8YYZQNv01o=.c3941281-9998-453b-82a7-5cfa3a2cc846@github.com>

On Tue, 2 Aug 2022 06:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's
>
> src/java.base/share/classes/java/lang/Class.java line 4682:
> 
>> 4680:      */
>> 4681:     private int getClassFileVersion() {
>> 4682:         Class<?> component = isArray() ? elementType() : this;
> 
> The variable name `component` seems completely not applicable now. I would just use `c`.

Done.

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

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

From hseigel at openjdk.org  Tue Aug  2 14:12:47 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Tue, 2 Aug 2022 14:12:47 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v3]
In-Reply-To: <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com>
 <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com>
Message-ID: <LXiFdCk2fkZy8TiVAm9Um0C17kcSWFvecl8Q4SPQmb4=.d374d183-021c-44b4-b4bb-4c6ec65be5d7@github.com>

On Tue, 2 Aug 2022 06:36:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No particular reason for choosing 59 other than it's different and less than 64.  Test case Version64_65535 has a non-zero minor version.
>
> I think we should be testing for other real classfile versions that may be encountered, such as 45.3

I added a test case for 45.3.

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

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

From rriggs at openjdk.org  Tue Aug  2 14:16:44 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 14:16:44 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v4]
In-Reply-To: <rCm2H_GtgIp6knv6fcrki-D9b7fsT9CTbx5IszFhXHk=.e2dfe2a8-28ca-44a2-9841-769acaabdc71@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <rCm2H_GtgIp6knv6fcrki-D9b7fsT9CTbx5IszFhXHk=.e2dfe2a8-28ca-44a2-9841-769acaabdc71@github.com>
Message-ID: <pOGqNz8LSkUgIbLeyIdG1Q6U87dbaXFgzLo9--fFfwY=.eede63a6-03a0-486d-92c3-b97612541fc2@github.com>

On Tue, 2 Aug 2022 13:58:52 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline max Integer.stringSize

Are there existing tests that validate the formatted results? 
If so, add this bug id to @bug tag of each test.
If not, please add a test.

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

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

From rriggs at openjdk.org  Tue Aug  2 14:45:55 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 14:45:55 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v3]
In-Reply-To: <ABiK1_0-jf-kY9WF8xpxMhyLjIPcSlwrBw79lVnfHWk=.d2228a62-b85a-409d-b4b8-495fb74fd111@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <ABiK1_0-jf-kY9WF8xpxMhyLjIPcSlwrBw79lVnfHWk=.d2228a62-b85a-409d-b4b8-495fb74fd111@github.com>
Message-ID: <CUkx85IGujM8vMtLpHVPZydeTAs7QLHVnfO3s7CY1Zk=.681b594f-5d56-4d95-b9ee-04d0d750eea1@github.com>

On Tue, 2 Aug 2022 14:12:44 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test case, minor renames

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From duke at openjdk.org  Tue Aug  2 15:30:39 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 15:30:39 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v5]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <jlgPGiB7SGQnxNAJZ3xsKeTIYR4vGwaVv5v--vmwUZU=.24da76a5-bbc0-4e44-92f9-2e7331f8f50e@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:

  Mark StackTraceElement SerialTest for bug 8291641

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/bbc683f3..e7b04faa

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

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

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

From bpb at openjdk.org  Tue Aug  2 15:34:46 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 15:34:46 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
 <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
 <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>
Message-ID: <iii9cIIFvvnw582FXPTPvMVEz1F2jTD96KYrxSnrKt4=.be54e202-ee9a-486a-a754-4eb38072b9f9@github.com>

On Tue, 2 Aug 2022 11:56:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I agree it's not worth it and maybe we just drop the check as per the JBS issue and update the spec to document the long standing behavior.

Agreed.

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

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

From duke at openjdk.org  Tue Aug  2 15:38:05 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 15:38:05 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v6]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <pJ1QIHJJORhAEB6FfSQYNpXxQGgAxo5s9o7ZXrgYWIU=.8dffdf4a-89a8-4949-b648-8209fd64ef2b@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with two additional commits since the last revision:

 - Mark StackTraceElement SerialTest for bug 8291641
 - Revert "Mark StackTraceElement SerialTest for bug 8291641"
   
   This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/e7b04faa..c93ac5af

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

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

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

From duke at openjdk.org  Tue Aug  2 15:42:46 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 2 Aug 2022 15:42:46 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v4]
In-Reply-To: <pOGqNz8LSkUgIbLeyIdG1Q6U87dbaXFgzLo9--fFfwY=.eede63a6-03a0-486d-92c3-b97612541fc2@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <rCm2H_GtgIp6knv6fcrki-D9b7fsT9CTbx5IszFhXHk=.e2dfe2a8-28ca-44a2-9841-769acaabdc71@github.com>
 <pOGqNz8LSkUgIbLeyIdG1Q6U87dbaXFgzLo9--fFfwY=.eede63a6-03a0-486d-92c3-b97612541fc2@github.com>
Message-ID: <-KPpCDDVr5amz9UrrD9dDneoG1pOc7HyPj9eZVonZyo=.c7458f94-56b2-4a61-a18c-162a97e218e8@github.com>

On Tue, 2 Aug 2022 14:13:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inline max Integer.stringSize
>
> Are there existing tests that validate the formatted results? 
> If so, add this bug id to @bug tag of each test.
> If not, please add a test.

Thanks @RogerRiggs , I added the bug ID to the existing StackTraceElement SerialTest which validates the structure of `StackTraceElement.toString()`

https://github.com/openjdk/jdk/blob/c93ac5af9bf5c3ea1fb4b20d9589dee55cebf871/test/jdk/java/lang/StackTraceElement/SerialTest.java#L26-L27

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

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

From rriggs at openjdk.org  Tue Aug  2 15:57:42 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 15:57:42 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v6]
In-Reply-To: <pJ1QIHJJORhAEB6FfSQYNpXxQGgAxo5s9o7ZXrgYWIU=.8dffdf4a-89a8-4949-b648-8209fd64ef2b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <pJ1QIHJJORhAEB6FfSQYNpXxQGgAxo5s9o7ZXrgYWIU=.8dffdf4a-89a8-4949-b648-8209fd64ef2b@github.com>
Message-ID: <0SMppec6rPl57WVdWdQYBhteSGK3QJQNNkJjjaQbAJw=.320df489-e45b-4aef-9b26-462543a95265@github.com>

On Tue, 2 Aug 2022 15:38:05 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>    
>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From duke at openjdk.org  Tue Aug  2 16:04:46 2022
From: duke at openjdk.org (duke)
Date: Tue, 2 Aug 2022 16:04:46 GMT
Subject: Withdrawn: 8279031: Add API note to ToolProvider about being
 reusable/reentrant
In-Reply-To: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
Message-ID: <vGdBDnQ9axAOHY7_4MZZ_X8C5m7BTkvsFmTmO9eLhTI=.8f8d616f-10ac-42b5-baef-f5895aab66fd@github.com>

On Mon, 23 May 2022 08:49:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This commit adds an  API note to ToolProvider about being reusable/reentrant.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Tue Aug  2 16:18:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 16:18:16 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8290047: Remove check for ':' at last position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/ff404d4b..1af2a4b4

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

  Stats: 26 lines in 6 files changed: 6 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9595.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595

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

From naoto at openjdk.org  Tue Aug  2 16:31:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Aug 2022 16:31:40 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
 <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>
Message-ID: <HjK3kXbc5EHjKmeNX5B2espel3KKdVxwrroi1k8TH8I=.d56b6d48-3ef0-4fa1-babf-0cf29e717e17@github.com>

On Tue, 2 Aug 2022 08:35:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.
>
> test/jdk/java/beans/XMLEncoder/Test4625418.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 4625418 8239965 8290488
> 
> I'm curious why this XMLEncoder test is updated, is this related to round trip?

Yes. The test assumes all code points below U+10000 have 1-1 roundtrip (c2b2c). Since the assumption is now not met with this change, I commented out the 864 entries.

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

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

From alanb at openjdk.org  Tue Aug  2 16:47:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 16:47:13 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
Message-ID: <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>

On Tue, 2 Aug 2022 16:18:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove check for ':' at last position

src/java.base/share/classes/java/nio/file/FileSystem.java line 307:

> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
> 306:      * </pre></blockquote>
> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.

We could flesh this out a bit more with something like:

"where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."

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

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

From duke at openjdk.org  Tue Aug  2 16:52:50 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 2 Aug 2022 16:52:50 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v7]
In-Reply-To: <hx0Gwb64XLSSsrrcuNpxJ1cnHRaFAghk4VSfxecrY0c=.a8512bfa-446a-42ec-8fdc-1059cdba3586@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <hx0Gwb64XLSSsrrcuNpxJ1cnHRaFAghk4VSfxecrY0c=.a8512bfa-446a-42ec-8fdc-1059cdba3586@github.com>
Message-ID: <A956LZebHnIGSt8Sbg9269Nlh5z0HfsZ72KOXGEwe00=.65f0ad0a-0a94-4503-a5c6-1a0bdd67945f@github.com>

On Thu, 30 Jun 2022 12:08:19 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
>> 
>> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288327: Inline privateGetParameters()

Let's wait a bit

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

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

From alanb at openjdk.org  Tue Aug  2 16:55:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 16:55:19 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <b64VG2VxbmMKsu3WyO9MeJvcJdYL1le0JO-Jy57OkXU=.92d068eb-9c81-4404-8d4e-50696e28e11b@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:05 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8290047: Improve description of syntaxAndPattern

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/1af2a4b4..b9de2604

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

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:08 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
 <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
Message-ID: <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>

On Tue, 2 Aug 2022 16:44:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290047: Remove check for ':' at last position
>
> src/java.base/share/classes/java/nio/file/FileSystem.java line 307:
> 
>> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
>> 306:      * </pre></blockquote>
>> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.
> 
> We could flesh this out a bit more with something like:
> 
> "where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."

That is better.

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:08 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
 <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
 <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>
Message-ID: <G3LmbI7dcKsKZwYsKI-as-9j46sSvicxQrXG6rG95N8=.13c2f876-fc5d-494e-b776-1ffecd6a23b9@github.com>

On Tue, 2 Aug 2022 17:01:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/FileSystem.java line 307:
>> 
>>> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
>>> 306:      * </pre></blockquote>
>>> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.
>> 
>> We could flesh this out a bit more with something like:
>> 
>> "where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."
>
> That is better.

So changed in b9de2604b74c1082c6b0fa10435405120b971e93.

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

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

From alanb at openjdk.org  Tue Aug  2 17:21:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:21:09 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <YSK9Ubc_oUPGd1q3e_nc9RuWWU7YqEJMXv7z7Pzev8E=.61ee1feb-5ad2-4d09-9143-101af8c6616a@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Tue Aug  2 17:27:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:27:25 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags.

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

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

From plevart at openjdk.org  Tue Aug  2 17:51:49 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 2 Aug 2022 17:51:49 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v7]
In-Reply-To: <A956LZebHnIGSt8Sbg9269Nlh5z0HfsZ72KOXGEwe00=.65f0ad0a-0a94-4503-a5c6-1a0bdd67945f@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <hx0Gwb64XLSSsrrcuNpxJ1cnHRaFAghk4VSfxecrY0c=.a8512bfa-446a-42ec-8fdc-1059cdba3586@github.com>
 <A956LZebHnIGSt8Sbg9269Nlh5z0HfsZ72KOXGEwe00=.65f0ad0a-0a94-4503-a5c6-1a0bdd67945f@github.com>
Message-ID: <XlwEIqaOIceEMRNVJCcm3VU8Cn8Mvm13mFJHow-D5XU=.6a441122-e1c9-41a0-8d48-f902a159d12b@github.com>

On Tue, 2 Aug 2022 16:49:07 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288327: Inline privateGetParameters()
>
> Let's wait a bit

@stsypanov Do you need a sponsor or are you waiting for some other reviewer?

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

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

From plevart at openjdk.org  Tue Aug  2 17:57:19 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 2 Aug 2022 17:57:19 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
In-Reply-To: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
Message-ID: <cNyUoXbMxBQlXcU1ZjHWpRrSI-kVseZgrl-m-X66j50=.d789899c-8c82-4b00-85f8-3f7c618923d6@github.com>

On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.

Ping! @rkennke maybe?

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

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

From rkennke at openjdk.org  Tue Aug  2 18:06:45 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 2 Aug 2022 18:06:45 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
In-Reply-To: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
Message-ID: <tr1O_lMEXmA8pcxfWBGyjeqdb4DsJ2kxXlX8Zvdo8C4=.cac2c64f-8d9d-4301-8a8b-bda6844caa51@github.com>

On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.

Does't it make sense to also test SerialGC?
Other than that it looks good.

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

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

From rriggs at openjdk.org  Tue Aug  2 18:08:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 18:08:48 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <UtXT1lzRoFIqjuRAUq2X-PvljUN9sjXpXnjKlknFYrI=.d353144c-fdb8-420c-aeb9-0393110bf843@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by rriggs (Reviewer).

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

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

From lancea at openjdk.org  Tue Aug  2 18:29:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Aug 2022 18:29:53 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <sL7mFC_V64KEGUpCIZZeBo-j9LXHE1TcSrPULilQECA=.b075c0cb-76e1-4662-9227-37a63604cf22@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by lancea (Reviewer).

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

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

From lmesnik at openjdk.org  Tue Aug  2 18:53:43 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Aug 2022 18:53:43 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <9udmozwzmOEm5-cfI85oeAVTafamwMrZj1-Y2q6mxLA=.1708e4bf-24ec-4d5b-9859-7129342628ab@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

Marked as reviewed by lmesnik (Reviewer).

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

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

From duke at openjdk.org  Tue Aug  2 19:48:44 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 2 Aug 2022 19:48:44 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v7]
In-Reply-To: <XlwEIqaOIceEMRNVJCcm3VU8Cn8Mvm13mFJHow-D5XU=.6a441122-e1c9-41a0-8d48-f902a159d12b@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <hx0Gwb64XLSSsrrcuNpxJ1cnHRaFAghk4VSfxecrY0c=.a8512bfa-446a-42ec-8fdc-1059cdba3586@github.com>
 <A956LZebHnIGSt8Sbg9269Nlh5z0HfsZ72KOXGEwe00=.65f0ad0a-0a94-4503-a5c6-1a0bdd67945f@github.com>
 <XlwEIqaOIceEMRNVJCcm3VU8Cn8Mvm13mFJHow-D5XU=.6a441122-e1c9-41a0-8d48-f902a159d12b@github.com>
Message-ID: <sgrOskr_oUN2hQxsQK-rg5LKLwqqx8HHflif_m4qDls=.55ccd296-29c4-4f34-8225-a49b03384372@github.com>

On Tue, 2 Aug 2022 17:48:07 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Let's wait a bit
>
> @stsypanov Do you need a sponsor or are you waiting for some other reviewer?

@plevart I don't think we need any more review for the change is simple

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

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

From rriggs at openjdk.org  Tue Aug  2 21:26:16 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 21:26:16 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v5]
In-Reply-To: <tbhhHvHT62PIqglDmGIg2RyA6Kq8wl7-p1CqF9qGq2Q=.91e062b9-1887-4184-8967-35b2d0d61773@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
 <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>
 <tUX-ZrLZol14PoteIR8om0IyuwCi7ZrjBJenooAA-8A=.dc29430a-5a8b-4b09-91e6-990b5d4d33da@github.com>
 <tbhhHvHT62PIqglDmGIg2RyA6Kq8wl7-p1CqF9qGq2Q=.91e062b9-1887-4184-8967-35b2d0d61773@github.com>
Message-ID: <Ot3HRJDhF-keVAAjm76cUO9s9DSZzs_kbm0ZggvdcmE=.4e791963-a81d-4b70-8216-9f649114032a@github.com>

On Mon, 1 Aug 2022 23:05:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Probably?by?creating and?using shared?instances of?`java.util.Function` which?would also?allow deduplicating?the?code.
>
>> Is there another way to implement this that does not create 19 anonymous classes with a single overloaded method?
> 
> Overriding a method in an enum constant specific class is one way to implement constant-specific behavior. Textually, I thought it had the advantage of having the class file version specific behavior close to the latest version behavior.
> 
> This could be refactored in various ways, such as having AccessFlag.locations(ClassFileFormatVersion cffv) start with a switch over the location which implemented the enum constant specific behavior. Or the set of parameters of the enum constructor could be augmented to cover more cases (empty until $VERSION, then $LOCATIONS, etc.), with constant-specific overrides just constants with unique patterns like STRICT.

True, many ways to factor the code.  Another possibility is add a field to the enum that holds a `java.util.Function<Iteger, Set<Location>>)` and initialize it each with a lambda of the code now in the locations(cffv) method that maps the cffv to the set of locations.

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

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

From bpb at openjdk.org  Tue Aug  2 21:53:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 21:53:01 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v6]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <VpmBBjA_3jVUnwPkwTEQmME-ulsJHcCWofeIFlzrjZ4=.3cb8a88a-494c-4548-8140-adf65007b397@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8290047: Update overlooked jtrfs and zipfs tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/b9de2604..b0eab55f

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

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

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

From dholmes at openjdk.org  Wed Aug  3 00:14:44 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 00:14:44 GMT
Subject: Withdrawn: Merge jdk19
In-Reply-To: <YhDC59xfU7IdFg8k43OF10-7nfn2Lecbmrbfu_kYPm0=.79a870f9-fc25-4770-a4b8-852bc30f2bb7@github.com>
References: <YhDC59xfU7IdFg8k43OF10-7nfn2Lecbmrbfu_kYPm0=.79a870f9-fc25-4770-a4b8-852bc30f2bb7@github.com>
Message-ID: <VmDLBEDOjMSYrPRSlBleNqf6ILIxDojrqfmduv6Gue8=.664281a0-adf2-472b-9b7e-9c90b3440817@github.com>

On Sat, 30 Jul 2022 07:22:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Wed Aug  3 00:19:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 00:19:22 GMT
Subject: RFR: Merge jdk19
Message-ID: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com>

Forward port JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0'
 - 8291512: Snippetize modules API examples

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9720&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9720&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9720/files
  Stats: 33 lines in 6 files changed: 6 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9720.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9720/head:pull/9720

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

From smarks at openjdk.org  Wed Aug  3 00:54:49 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 00:54:49 GMT
Subject: RFR: 8290036: adjustments to specification of Runtime::addShutdownHook
Message-ID: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>

Initial edits to addShutdownHook from Alex.

See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

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

Commit messages:
 - Additional wording changes to Runtime specs.
 - HTML fixups; updates in response to review comments.
 - Updates to Runtime class spec, exit, halt, and System.exit
 - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
 - First cut at new shutdown sequence text.
 - Initial edits to addShutdownHook from Alex

Changes: https://git.openjdk.org/jdk/pull/9437/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290036
  Stats: 140 lines in 2 files changed: 56 ins; 45 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

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

From dholmes at openjdk.org  Wed Aug  3 00:54:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 00:54:51 GMT
Subject: RFR: 8290036: adjustments to specification of
 Runtime::addShutdownHook
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <Z01QToODtLb0kCvLke1z2HhCKn86GZR4xsd1dnh-rrA=.60d29411-f507-4a56-a151-99ab726ebb70@github.com>

On Fri, 8 Jul 2022 23:00:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Hi Stuart,

There's nothing I would consider harmful in these changes, but I also don't see them as necessary.

Cheers.

src/java.base/share/classes/java/lang/Runtime.java line 145:

> 143:      * can create and start new threads during the shutdown sequence; the new
> 144:      * threads execute concurrently with their creators and may create and
> 145:      * start further threads.

True - but does it really need to be singled out for mention? I think explicitly pointing this out will just lead to follow up queries as to how such threads interact with the shutdown sequence.

src/java.base/share/classes/java/lang/Runtime.java line 175:

> 173:      * or loops infinitely) will prevent the shutdown sequence from completing.
> 174:      * In this case, the virtual machine can still be halted if a daemon or
> 175:      * non-daemon thread which is still running calls {@link #halt halt}.

Lines 174-175 basically repeat what was already said at lines 147-149

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

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

From smarks at openjdk.org  Wed Aug  3 00:54:51 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 00:54:51 GMT
Subject: RFR: 8290036: adjustments to specification of
 Runtime::addShutdownHook
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <Zq2Y_ZJ_qg5Quex_u_PD8Fvo8C9FcdpRzqZLDIF2csY=.1fcc7aff-6b0f-42f0-b376-4dfad544f36c@github.com>

On Fri, 8 Jul 2022 23:00:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Sorry David I should have clarified this a bit. The changes currently in this draft PR are merely what occurred to Alex and me while we were working on JLS 12.8. There are a bunch of other issues that need to be covered or at clarified clarified here, or possibly in the Runtime class specification. I'll add them to the bug report, and eventually we'll update this PR with further changes.

Discussion of the changes in this PR are taking place in the bug report:

https://bugs.openjdk.org/browse/JDK-8290036

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

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

From xgong at openjdk.org  Wed Aug  3 01:31:47 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 3 Aug 2022 01:31:47 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <08bR9UZLfXAdUGA4Yfh1k0VEVQvUuqWNZ9URbIxdy_0=.43a69600-fb06-4d6e-b209-f02e651097db@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

Hi, could anyone please take a look at this change? Thanks a lot!

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

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

From aoqi at openjdk.org  Wed Aug  3 02:34:48 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 02:34:48 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  update tags order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/1e00cd83..2ea9e1a9

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

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

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

From aoqi at openjdk.org  Wed Aug  3 02:36:03 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 02:36:03 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
 <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
Message-ID: <ga517T_Y4c-YsmdoMXQdVMQMggNA9yVlarfwuL8uCGU=.f20e6093-450d-410b-a85f-f0a9964e8b79@github.com>

On Tue, 2 Aug 2022 17:25:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags.

Done. Didn't know that. Thank you for the reminder.

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

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

From smarks at openjdk.org  Wed Aug  3 02:43:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 02:43:42 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: <PkzbnaV2uBAxJDgt07cV-Jl8_o3GF-y_OISmYebpjl8=.7c238dbc-787d-4a1f-8176-c3951e5ddfc4@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

Hi Peter, thanks for contributing to this. I think you're observing that as a practical matter, the implementations of GC and of various libraries such as reference queues must see a consistent view of memory in order for anything to work. This seems right. However, I'm concerned about what the _specification_ says, or ought to say.

Hans seems to think that the JLS assertions about finalization also apply to reference processing. I'm not so sure... that seems to me to be a rather generous interpretation. On the face of it, I cannot find anything explicit in the specifications that supports it. It certainly seems reasonable (to me) that reachabilityFence(x) ought to HB the corresponding reference being dequeued. If so I would like the specification to say that. (The fact that there is a GC thread that enqueues the reference is part of the implementation, which is opaque to the specification.) It may also be the that any point where the referent is reachable HB its corresponding reference is dequeued. Clearly the GC implementation needs to make sure this is the case; the questions in my mind are whether, where, and how this should be specified!

It may be that the VarHandle fences aren't necessary. However, if they end up driving the right updates to the specifications, they will have served their purpose.

Setting this aside, it does seem like all uses of a cleanable object need to have a try/finally statement, with at least an RF in the finally clause. Is there any evidence that shows that this construct isn't needed?

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

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

From hboehm at google.com  Wed Aug  3 03:22:29 2022
From: hboehm at google.com (Hans Boehm)
Date: Tue, 2 Aug 2022 20:22:29 -0700
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
 finalizer to Cleaner [v16]
In-Reply-To: <PkzbnaV2uBAxJDgt07cV-Jl8_o3GF-y_OISmYebpjl8=.7c238dbc-787d-4a1f-8176-c3951e5ddfc4@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
 <PkzbnaV2uBAxJDgt07cV-Jl8_o3GF-y_OISmYebpjl8=.7c238dbc-787d-4a1f-8176-c3951e5ddfc4@github.com>
Message-ID: <CAMOCf+hZgn+8x7tBmEpbqK0qUrYk0PbVH++hsGsq0dxFPkdhRA@mail.gmail.com>

On Tue, Aug 2, 2022 at 7:43 PM Stuart Marks <smarks at openjdk.org> wrote:

> ...
> Setting this aside, it does seem like all uses of a cleanable object need
> to have a try/finally statement, with at least an RF in the finally clause.
> Is there any evidence that shows that this construct isn't needed?
>
I think the reachabilityFence is clearly needed with current
implementations, though their omission is hard to test for, since the
failures tend to only occur with unlikely schedules. But those schedules
clearly exist. And fixing implementations to avoid that by unconditionally
preserving references is problematic, especially given that bytecode tends
to hide scopes. (Back during Java memory model discussions, there was also
an argument that this would cause us to pay everywhere for a rarely used
feature. I believe the "rarely used" part less and less. On the other hand,
I also now tend to view a percent or two performance difference as more
significant than back then, so maybe that overall argument still applies.)

I would also guess that the try-finally is required by some current
optimizations. But that's more based on an argument that such optimizations
exist, so somebody must have implemented them, rather than anything more
concrete.

Hans


> -------------
>
> PR: https://git.openjdk.org/jdk/pull/8311
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220802/49ce514e/attachment.htm>

From david.holmes at oracle.com  Wed Aug  3 05:12:09 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 3 Aug 2022 15:12:09 +1000
Subject: Withdrawn: Merge jdk19
In-Reply-To: <VmDLBEDOjMSYrPRSlBleNqf6ILIxDojrqfmduv6Gue8=.664281a0-adf2-472b-9b7e-9c90b3440817@github.com>
References: <YhDC59xfU7IdFg8k43OF10-7nfn2Lecbmrbfu_kYPm0=.79a870f9-fc25-4770-a4b8-852bc30f2bb7@github.com>
 <VmDLBEDOjMSYrPRSlBleNqf6ILIxDojrqfmduv6Gue8=.664281a0-adf2-472b-9b7e-9c90b3440817@github.com>
Message-ID: <74fa24e4-5a3a-6aa7-7258-e34b627b1df3@oracle.com>

No idea what happened here but am redoing as:

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

David

On 3/08/2022 10:14 am, David Holmes wrote:
> On Sat, 30 Jul 2022 07:22:38 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Forward port JDK 19 -> JDK 20
> 
> This pull request has been closed without being integrated.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/9692

From dholmes at openjdk.org  Wed Aug  3 05:13:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 05:13:42 GMT
Subject: Withdrawn: Merge jdk19
In-Reply-To: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com>
References: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com>
Message-ID: <rLRlfp7tB2ifgWbJ3NypQsii8u_aMW-fHr77ruGqbok=.f1d214ed-4444-48ac-b076-b8d3a3911448@github.com>

On Wed, 3 Aug 2022 00:12:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Wed Aug  3 05:19:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 05:19:01 GMT
Subject: RFR: Merge jdk19
Message-ID: <XHcygt53hVMd_0f9sfukHmj0G9iE55HYNFwACGxiSAs=.5521554b-df48-42e6-bd64-3e20bd4ecf31@github.com>

Forward port JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0'
 - 8291512: Snippetize modules API examples

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9721&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9721&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9721/files
  Stats: 33 lines in 6 files changed: 6 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9721.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9721/head:pull/9721

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

From plevart at openjdk.org  Wed Aug  3 06:24:16 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 3 Aug 2022 06:24:16 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v2]
In-Reply-To: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
Message-ID: <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>

> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Add SerialGC variant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9684/files
  - new: https://git.openjdk.org/jdk/pull/9684/files/6d66354e..88f29edd

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

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

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

From plevart at openjdk.org  Wed Aug  3 06:24:17 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 3 Aug 2022 06:24:17 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v2]
In-Reply-To: <tr1O_lMEXmA8pcxfWBGyjeqdb4DsJ2kxXlX8Zvdo8C4=.cac2c64f-8d9d-4301-8a8b-bda6844caa51@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <tr1O_lMEXmA8pcxfWBGyjeqdb4DsJ2kxXlX8Zvdo8C4=.cac2c64f-8d9d-4301-8a8b-bda6844caa51@github.com>
Message-ID: <LiyRXmqBeZ1mHmAafD_LOquFpLQl1pNaAYcTvO5jev4=.ac5eefbe-2c7e-4f08-a719-126f7c5a17cd@github.com>

On Tue, 2 Aug 2022 18:03:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Does't it make sense to also test SerialGC? Other than that it looks good.

Added SerialGC variant and it passes the test.

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

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

From dholmes at openjdk.org  Wed Aug  3 08:14:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 08:14:45 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <XHcygt53hVMd_0f9sfukHmj0G9iE55HYNFwACGxiSAs=.5521554b-df48-42e6-bd64-3e20bd4ecf31@github.com>
References: <XHcygt53hVMd_0f9sfukHmj0G9iE55HYNFwACGxiSAs=.5521554b-df48-42e6-bd64-3e20bd4ecf31@github.com>
Message-ID: <LL-uP6yw9uH5KuaTts0jwWT3e4ISmLOLMh-rQJAd6NY=.d50be5d6-8a56-47cb-9741-c1907a9cac78@github.com>

On Wed, 3 Aug 2022 05:10:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 0971d346
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0971d3464609bf4124df460ea73ff761d7e0f7b2
Stats:     33 lines in 6 files changed: 6 ins; 9 del; 18 mod

Merge

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

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

From duke at openjdk.org  Wed Aug  3 09:06:39 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 3 Aug 2022 09:06:39 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v7]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

 - remove line
 - add export

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/4d5faab3..6a524606

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

  Stats: 46 lines in 5 files changed: 23 ins; 21 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372

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

From alanb at openjdk.org  Wed Aug  3 09:14:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 09:14:44 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v7]
In-Reply-To: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
Message-ID: <Hk6PusjOxKZgi0ACnTXGGFO9CCmg5YTquGvHIeWuBYU=.369b5231-7a68-4c4e-a738-4ae75e2ab577@github.com>

On Wed, 3 Aug 2022 09:06:39 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove line
>  - add export

src/java.management/share/classes/module-info.java line 52:

> 50:     exports javax.management.remote;
> 51:     exports javax.management.timer;
> 52:     exports java.lang.management.internal.mBeans;

This package should not be exported (at least not to all modules).

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

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

From alanb at openjdk.org  Wed Aug  3 09:20:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 09:20:29 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v7]
In-Reply-To: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
Message-ID: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com>

On Wed, 3 Aug 2022 09:06:39 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove line
>  - add export

What happened with the experiment to move ContainerInfoMXBean to jdk.management?

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

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

From duke at openjdk.org  Wed Aug  3 09:51:06 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 3 Aug 2022 09:51:06 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v8]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  move ContainerInfoMXBean to jdk.management

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/6a524606..0aa0ffb4

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

  Stats: 49 lines in 5 files changed: 25 ins; 20 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372

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

From duke at openjdk.org  Wed Aug  3 10:36:06 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 3 Aug 2022 10:36:06 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v9]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  Revert file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/0aa0ffb4..2c149c10

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

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

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

From duke at openjdk.org  Wed Aug  3 10:38:51 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 3 Aug 2022 10:38:51 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v8]
In-Reply-To: <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com>
Message-ID: <0MRzjXC_Nf03b9VlFbeMo4UMOTW4zf4CQqQkWtpZbfg=.ae7f34fa-f44c-42b2-bf92-6f4fb26828f0@github.com>

On Wed, 3 Aug 2022 09:51:06 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move ContainerInfoMXBean to jdk.management

Thanks for review.
@AlanBateman 
I found my code bug and it has been fixed.
Moving ContainerInfo is feasible

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

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

From duke at openjdk.org  Wed Aug  3 10:40:41 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 3 Aug 2022 10:40:41 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v9]
In-Reply-To: <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com>
Message-ID: <L8hrCFA61JDjK9ixCkW-aOQtip4SzlygcCtQkFSA6gU=.108f69c2-3a0e-4158-bdb7-08b889a4a430@github.com>

On Wed, 3 Aug 2022 10:36:06 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert file

![??](https://user-images.githubusercontent.com/7837910/182588282-4958e976-e322-48b2-865f-5111b04960eb.png)

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

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

From rkennke at openjdk.org  Wed Aug  3 10:40:43 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 3 Aug 2022 10:40:43 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v2]
In-Reply-To: <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
Message-ID: <nXF1nEelF33h5TrTvYxi3XjVMzJ_FYSYyB7apRF2yGE=.9a06fc75-530b-4285-a44f-7bf1c87f6bcb@github.com>

On Wed, 3 Aug 2022 06:24:16 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
>> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
>> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
>> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SerialGC variant

Looks good to me. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

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

From alanb at openjdk.org  Wed Aug  3 10:52:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 10:52:43 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <6hRAKer8eW6kUHAIv-xHtLffshGe2OMmXiJe-wbmdHM=.ab4418e2-f40c-44c0-b546-686f0d09ef74@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update tags order

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.org  Wed Aug  3 11:03:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 Aug 2022 11:03:40 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <CflYKTgGuEth9cBpvx-_nme9-IyesWKwtVvPN7mcTvI=.9e217399-8639-4bcc-bfb0-a8eb59531176@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Changes to HttpURLConnection look good to me

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

Marked as reviewed by dfuchs (Reviewer).

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

From shade at openjdk.org  Wed Aug  3 11:27:53 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Aug 2022 11:27:53 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v2]
In-Reply-To: <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
Message-ID: <KqVJU749sWLaHTnkNQvT3VhRjeeLy9NvLSQAJAq6QKQ=.13cdd856-993c-4f94-84cf-178f556023d4@github.com>

On Wed, 3 Aug 2022 06:24:16 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
>> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
>> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
>> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SerialGC variant

Looks good with minor nits. I tested with 100 repeats, and it passes:


$ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java JTREG="REPEAT_COUNT=100"

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

This update is incorrect, should be:

Suggestion:

 * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 34:

> 32: 
> 33: /*
> 34:  * @test id=with_G1GC

The test identifiers can be just "G1", "Parallel", "Serial", etc.

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 72:

> 70:     /**
> 71:      * Test methods execute in same VM and are ordered by name.
> 72:      * We test effectiveness 1st which is sensitive to previous allocations when ZGC is used.

Comment mentions ZGC?

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 103:

> 101:         assertFalse(
> 102:             ref1.refersTo(null),
> 103:             "Cache lost entry together with WeakReference being cleared although memory was not under pressure"

Style:

Suggestion:

        assertFalse(ref1.refersTo(null),
                    "Cache lost entry together with WeakReference being cleared although memory was not under pressure"

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

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

From dfuchs at openjdk.org  Wed Aug  3 12:59:52 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 Aug 2022 12:59:52 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v7]
In-Reply-To: <ChaN7Or-WFl_OuuI2kA3O-FjIEWHP4AY7gpdpEAXfAQ=.ff791084-546a-4177-8e42-5787c1ece930@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <ChaN7Or-WFl_OuuI2kA3O-FjIEWHP4AY7gpdpEAXfAQ=.ff791084-546a-4177-8e42-5787c1ece930@github.com>
Message-ID: <s8TQuSprFm0zsRCa23TDLTqJ1rQ3VRW6ScrB4atamZg=.565c86d5-096b-46de-a83e-1cdea77bbdf7@github.com>

On Wed, 20 Jul 2022 23:41:04 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.
>
> 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 12 additional commits since the last revision:
> 
>  - 6478546: Miscellaneous cleanup
>  - Merge
>  - Merge
>  - 6478546: Use dynamically sized temporary direct buffers
>  - Merge
>  - Merge
>  - 6478546: Add break in write loop on ExceptionOccurred
>  - Merge
>  - 6478546: Clean up io_util.c
>  - Merge
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a3b1a325...9a138636

src/java.base/share/classes/java/io/RandomAccessFile.java line 112:

> 110:         }
> 111: 
> 112:         int multiple = (len + MIN_BUFFER_SIZE - 1)/MIN_BUFFER_SIZE;

isn't that equivalent `(len / MIN_BUFFER_SIZE) + 1`, given that len cannot be 0 or a multiple of MIN_BUFFER_SIZE?

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

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

From djelinski at openjdk.org  Wed Aug  3 14:08:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Aug 2022 14:08:07 GMT
Subject: RFR: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
Message-ID: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>

This patch fixes the test to use the same locale as the tested code

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

Commit messages:
 - CustomZoneNameTest fails if default locale does not match defaultFormatLocale

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

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

From itakiguchi at openjdk.org  Wed Aug  3 14:11:40 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 3 Aug 2022 14:11:40 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

I think you can ignore my comments.
I'm not sure if this change will solve the reporter's issue...

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

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

From lancea at openjdk.org  Wed Aug  3 14:41:26 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 3 Aug 2022 14:41:26 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
Message-ID: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>

Hi,

Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 

Mach5 tiers1-3 have been run without failure

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

Commit messages:
 - Fix for JDK-8288769

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

PR: https://git.openjdk.org/jdk19/pull/159

From iris at openjdk.org  Wed Aug  3 15:33:40 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 Aug 2022 15:33:40 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
Message-ID: <6XQI2a0cQPf7cCpnWLMbroYfBTf9mYh-mXNvji8ePkA=.cd479eae-672b-4b52-9754-a2ea0cccf815@github.com>

On Wed, 3 Aug 2022 10:21:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 
> 
> Mach5 tiers1-3 have been run without failure

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/159

From bpb at openjdk.org  Wed Aug  3 15:46:07 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 15:46:07 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v7]
In-Reply-To: <s8TQuSprFm0zsRCa23TDLTqJ1rQ3VRW6ScrB4atamZg=.565c86d5-096b-46de-a83e-1cdea77bbdf7@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <ChaN7Or-WFl_OuuI2kA3O-FjIEWHP4AY7gpdpEAXfAQ=.ff791084-546a-4177-8e42-5787c1ece930@github.com>
 <s8TQuSprFm0zsRCa23TDLTqJ1rQ3VRW6ScrB4atamZg=.565c86d5-096b-46de-a83e-1cdea77bbdf7@github.com>
Message-ID: <uI1cOeGgxxoZlQ3kXb172sNV905ZyeyWtzenFHVFH-I=.b439f5b0-4619-4e84-9fbd-db8497393919@github.com>

On Wed, 3 Aug 2022 12:54:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - 6478546: Miscellaneous cleanup
>>  - Merge
>>  - Merge
>>  - 6478546: Use dynamically sized temporary direct buffers
>>  - Merge
>>  - Merge
>>  - 6478546: Add break in write loop on ExceptionOccurred
>>  - Merge
>>  - 6478546: Clean up io_util.c
>>  - Merge
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/fd00ab21...9a138636
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 112:
> 
>> 110:         }
>> 111: 
>> 112:         int multiple = (len + MIN_BUFFER_SIZE - 1)/MIN_BUFFER_SIZE;
> 
> isn't that equivalent `(len / MIN_BUFFER_SIZE) + 1`, given that len cannot be 0 or a multiple of MIN_BUFFER_SIZE?

Yes, I think you are correct. Good catch!

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

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

From naoto at openjdk.org  Wed Aug  3 16:03:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 16:03:45 GMT
Subject: Integrated: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <M43QL4lwZ4nFwGPJb4u8tx21xMGOTCgUAk4r30gKpGo=.33a8fcfb-b13a-4496-9fff-184329395b6c@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

This pull request has now been integrated.

Changeset: e52a340d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e52a340d7fca161539524eedc0c2d48283f4f0a7
Stats:     6 lines in 3 files changed: 2 ins; 0 del; 4 mod

8290488: IBM864 character encoding implementation bug

Reviewed-by: iris, joehw, alanb

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

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

From bpb at openjdk.org  Wed Aug  3 16:09:40 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 16:09:40 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
Message-ID: <2e2TAL5MHKzowIGwrm3btboe9BZbpfzErppwvIuFGSU=.b246dfe1-692e-4844-965e-8a490621f7a8@github.com>

On Wed, 3 Aug 2022 10:21:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 
> 
> Mach5 tiers1-3 have been run without failure

+1

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/159

From naoto at openjdk.org  Wed Aug  3 16:17:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 16:17:51 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
 <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>
Message-ID: <axRevRchJX0lfCIOsDhv3kS3CNJVZm9RsZtbW3Z_oqQ=.943c7aec-9934-4ace-a2fa-a53624c10804@github.com>

On Wed, 3 Aug 2022 14:08:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I'm not sure if this change will solve the reporter's issue...

It does solve the submitter's issue. With this fix:

jshell> HexFormat.ofDelimiter(" ").formatHex("<%adc".getBytes("IBM864"))
$181 ==> "3c 25 61 64 63"

which is exactly the expected result.

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

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

From alanb at openjdk.org  Wed Aug  3 16:30:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 16:30:55 GMT
Subject: RFR: 8290036: adjustments to specification of
 Runtime::addShutdownHook
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <pQzSrmh1t4uaLnFWSiBVchn1lYP3GpPtc7vptm3WGAM=.f32fb2c4-9a9a-424f-aa1a-1949cc45b41e@github.com>

On Fri, 8 Jul 2022 23:00:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

src/java.base/share/classes/java/lang/Runtime.java line 69:

> 67:  * and
> 68:  * {@link #removeShutdownHook removeShutdownHook}
> 69:  * is prohibited. The shutdown hooks are then started in some unspecified order,

Are you planning to "reflow" to get the line lengths a bit more consistent? Only asking because some places after line breaks after 40-50 characters, a few others stray out beyond 100 characters.

src/java.base/share/classes/java/lang/Runtime.java line 71:

> 69:  * is prohibited. The shutdown hooks are then started in some unspecified order,
> 70:  * and they are allowed to run concurrently. Any already-existing threads and any
> 71:  * newly started threads also continue to run concurrently during the shutdown sequence.

Instead of "Any already-existing threads" then you could say "Existing {@linkplain Thread#isAlive() live} threads".

src/java.base/share/classes/java/lang/Runtime.java line 78:

> 76:  * In this case other threads (including shutdown hooks) continue to execute and can
> 77:  * terminate the JVM via the {@link #halt halt} method.
> 78:  * <h2><a id="termination">Virtual Machine Termination</a></h2>

You might want to insert a line break at the end of the "Shutdown Sequence" section so that it doesn't run into the "Virtual Machine Termination" section.

src/java.base/share/classes/java/lang/Runtime.java line 79:

> 77:  * terminate the JVM via the {@link #halt halt} method.
> 78:  * <h2><a id="termination">Virtual Machine Termination</a></h2>
> 79:  * When the JVM terminates, all threads (daemon, non-daemon, and shutdown hooks) are immediately

"daemon, non-daemon, and shutdown hooks" reads like there are 3 kinds of threads. I would be tempted to drop "shutdown hooks" from this list or else phrase it as "all shutdown hooks and all other threads".

src/java.base/share/classes/java/lang/Runtime.java line 174:

> 172:      * Uncaught exceptions are handled in shutdown hooks just as in any other thread,
> 173:      * by invoking the {@link ThreadGroup#uncaughtException uncaughtException}
> 174:      * method of the thread's {@link ThreadGroup} object. After the uncaught exception

Uncaught exception handling is a bit more complicated as there can be per-thread and default UHE set. I think it would be better to not mention ThreadGroup and instead just link to Thread#setDefaultUncaughtExceptionHandler.

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

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

From ecaspole at openjdk.org  Wed Aug  3 16:35:41 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 3 Aug 2022 16:35:41 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
Message-ID: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>

These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.

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

Commit messages:
 - 8291828: Reduce runtime of java.util.stream microbenchmarks

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

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

From naoto at openjdk.org  Wed Aug  3 17:04:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 17:04:39 GMT
Subject: RFR: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
In-Reply-To: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
References: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
Message-ID: <FvOIgQxQb2zOUz3gZbbP4ccddSNiSUUHTLZImJrHyps=.83f4fb1c-5071-47c9-8847-ae8f7f22a50e@github.com>

On Wed, 3 Aug 2022 13:55:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the test to use the same locale as the tested code

LGTM. Thanks for the fix!

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

Marked as reviewed by naoto (Reviewer).

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

From bpb at openjdk.org  Wed Aug  3 17:14:13 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 17:14:13 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v8]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <YMzDrRyHBqq2_DMtkH1p8MftKQKbw-3l3aXHxnDyAvI=.62d63506-8745-46ca-872e-2c8a8826b696@github.com>

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

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 14 additional commits since the last revision:

 - 6478546: Eliminate a subtraction from RandomAccessFile.bufferSize()
 - Merge
 - 6478546: Miscellaneous cleanup
 - Merge
 - Merge
 - 6478546: Use dynamically sized temporary direct buffers
 - Merge
 - Merge
 - 6478546: Add break in write loop on ExceptionOccurred
 - Merge
 - ... and 4 more: https://git.openjdk.org/jdk/compare/8ee41b0d...9d7e4fbf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8235/files
  - new: https://git.openjdk.org/jdk/pull/8235/files/9a138636..9d7e4fbf

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

  Stats: 12332 lines in 522 files changed: 6560 ins; 4360 del; 1412 mod
  Patch: https://git.openjdk.org/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8235/head:pull/8235

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

From bpb at openjdk.org  Wed Aug  3 17:14:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 17:14:17 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v7]
In-Reply-To: <uI1cOeGgxxoZlQ3kXb172sNV905ZyeyWtzenFHVFH-I=.b439f5b0-4619-4e84-9fbd-db8497393919@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <ChaN7Or-WFl_OuuI2kA3O-FjIEWHP4AY7gpdpEAXfAQ=.ff791084-546a-4177-8e42-5787c1ece930@github.com>
 <s8TQuSprFm0zsRCa23TDLTqJ1rQ3VRW6ScrB4atamZg=.565c86d5-096b-46de-a83e-1cdea77bbdf7@github.com>
 <uI1cOeGgxxoZlQ3kXb172sNV905ZyeyWtzenFHVFH-I=.b439f5b0-4619-4e84-9fbd-db8497393919@github.com>
Message-ID: <qgIrhTLggZf4-GkmqoPcoD1SnoLDJsWqqOmJTM0MofQ=.35bf1e24-38f7-466b-a07f-eadcd61435b2@github.com>

On Wed, 3 Aug 2022 15:42:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/RandomAccessFile.java line 112:
>> 
>>> 110:         }
>>> 111: 
>>> 112:         int multiple = (len + MIN_BUFFER_SIZE - 1)/MIN_BUFFER_SIZE;
>> 
>> isn't that equivalent `(len / MIN_BUFFER_SIZE) + 1`, given that len cannot be 0 or a multiple of MIN_BUFFER_SIZE?
>
> Yes, I think you are correct. Good catch!

So changed in 9d7e4fbf39668ff3938b5f0f35d2e997ebbd9777.

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

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

From sspitsyn at openjdk.org  Wed Aug  3 17:34:22 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Aug 2022 17:34:22 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <feOKmPYl5W1JQLFVLPQrblg18RKtcs6QQ4eEfPmCg4A=.8d1b1f89-14dc-45ac-acbb-58a3736faf51@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update tags order

Marked as reviewed by sspitsyn (Reviewer).

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

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

From aoqi at openjdk.org  Wed Aug  3 17:36:14 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 17:36:14 GMT
Subject: Integrated: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations"
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <shaZMSKrDCJTmFW5jYfs8ZWjLRlPvb8DEAaZdfR6IQI=.59c352ff-dcc9-4012-b044-b2513021cd3c@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

This pull request has now been integrated.

Changeset: 0cc49fd9
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cc49fd9eac5259543a3c41b7a32b6e01a1b0ad5
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8291508: Fix some tests with "requires vm.jvmti & vm.continuations"

Reviewed-by: sspitsyn, lmesnik, alanb

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

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

From plevart at openjdk.org  Wed Aug  3 22:17:38 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 3 Aug 2022 22:17:38 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v3]
In-Reply-To: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
Message-ID: <XX_C2Cez7VS_JhulZTlsfQ8K-bGbY62ozFcYZL2z0bw=.ffcdefa2-16e1-42f9-acf6-1c24ecc0f9f1@github.com>

> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Nits from review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9684/files
  - new: https://git.openjdk.org/jdk/pull/9684/files/88f29edd..493740ca

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

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

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

From plevart at openjdk.org  Wed Aug  3 22:17:42 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 3 Aug 2022 22:17:42 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v2]
In-Reply-To: <KqVJU749sWLaHTnkNQvT3VhRjeeLy9NvLSQAJAq6QKQ=.13cdd856-993c-4f94-84cf-178f556023d4@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
 <KqVJU749sWLaHTnkNQvT3VhRjeeLy9NvLSQAJAq6QKQ=.13cdd856-993c-4f94-84cf-178f556023d4@github.com>
Message-ID: <7N2O7rZvakmSYwSKAAa6ApzE9vxvli71L65dVI65nAI=.276a9465-8729-4437-b2d0-c51c9377fb3b@github.com>

On Wed, 3 Aug 2022 11:12:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add SerialGC variant
>
> test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> This update is incorrect, should be:
> 
> Suggestion:
> 
>  * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

Corrected in next commit.

> test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 103:
> 
>> 101:         assertFalse(
>> 102:             ref1.refersTo(null),
>> 103:             "Cache lost entry together with WeakReference being cleared although memory was not under pressure"
> 
> Style:
> 
> Suggestion:
> 
>         assertFalse(ref1.refersTo(null),
>                     "Cache lost entry together with WeakReference being cleared although memory was not under pressure"

Modified in next commit

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

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

From plevart at openjdk.org  Wed Aug  3 22:17:45 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 3 Aug 2022 22:17:45 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v3]
In-Reply-To: <KqVJU749sWLaHTnkNQvT3VhRjeeLy9NvLSQAJAq6QKQ=.13cdd856-993c-4f94-84cf-178f556023d4@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <ZKK58jkE0TEds8mfa1SMPQxazH1CgqzPLOgJUYOcuh8=.bc602ee0-dda2-426e-8174-065e581381de@github.com>
 <KqVJU749sWLaHTnkNQvT3VhRjeeLy9NvLSQAJAq6QKQ=.13cdd856-993c-4f94-84cf-178f556023d4@github.com>
Message-ID: <3h3z-N9K2PXglWdbLuLPN5u3A-uEiUnaXFe-zlllaTc=.9be1dfd1-f01a-478c-bf61-30d945dfbfc8@github.com>

On Fri, 29 Jul 2022 09:38:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Nits from review comments
>
> test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 34:
> 
>> 32: 
>> 33: /*
>> 34:  * @test id=with_G1GC
> 
> The test identifiers can be just "G1", "Parallel", "Serial", etc.

I found a test where those identifiers were used, but now I see other tests where shorter id(s) are used and they are in majority. Adjusted accordingly in next commit.

> test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 72:
> 
>> 70:     /**
>> 71:      * Test methods execute in same VM and are ordered by name.
>> 72:      * We test effectiveness 1st which is sensitive to previous allocations when ZGC is used.
> 
> Comment mentions ZGC?

Yes, only with ZGC I found it is necessary to respect this order of testing otherwise the test might fail.

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

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

From xgong at openjdk.org  Thu Aug  4 01:54:01 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 4 Aug 2022 01:54:01 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <ganQLPytlk_6sEl9MYeYay3uWMBhUqdfonJROwF0F6Y=.ff30e516-2f62-4892-a44c-b538f1423ceb@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

Hi @PaulSandoz , could you please take a look at this simple change? Thanks a lot for your time!

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

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

From eliu at openjdk.org  Thu Aug  4 02:04:05 2022
From: eliu at openjdk.org (Eric Liu)
Date: Thu, 4 Aug 2022 02:04:05 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <0Zw3xLOwMpG0T8_TkH6TEiyi5B6GtroI_QrE3Hl42JU=.6921ec98-fcee-437a-9161-a2577ca3946f@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

LGTM.

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

Marked as reviewed by eliu (Author).

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

From smarks at openjdk.org  Thu Aug  4 02:55:57 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 4 Aug 2022 02:55:57 GMT
Subject: RFR: 8290036: adjustments to specification of
 Runtime::addShutdownHook
In-Reply-To: <pQzSrmh1t4uaLnFWSiBVchn1lYP3GpPtc7vptm3WGAM=.f32fb2c4-9a9a-424f-aa1a-1949cc45b41e@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <pQzSrmh1t4uaLnFWSiBVchn1lYP3GpPtc7vptm3WGAM=.f32fb2c4-9a9a-424f-aa1a-1949cc45b41e@github.com>
Message-ID: <Tt1qKHbWsU9d34DXh3GQVrCd5Y_zUrF82LlUUcATNuY=.c5795f86-f574-4321-83fa-6e7676b46726@github.com>

On Wed, 3 Aug 2022 16:19:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Initial edits to addShutdownHook from Alex.
>> 
>> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).
>
> src/java.base/share/classes/java/lang/Runtime.java line 79:
> 
>> 77:  * terminate the JVM via the {@link #halt halt} method.
>> 78:  * <h2><a id="termination">Virtual Machine Termination</a></h2>
>> 79:  * When the JVM terminates, all threads (daemon, non-daemon, and shutdown hooks) are immediately
> 
> "daemon, non-daemon, and shutdown hooks" reads like there are 3 kinds of threads. I would be tempted to drop "shutdown hooks" from this list or else phrase it as "all shutdown hooks and all other threads".

Alex and I discussed this and we felt that it was important to call out all three "kinds" of threads explicitly. Earlier versions of the text implied that no non-daemon threads were running at the time the VM terminated, which might not be true. Earlier text also implied that shutdown hooks had terminated before the VM terminated, but this isn't necessarily true if somebody calls halt(). Yes, a shutdown hook has a daemon/non-daemon bit, but effectively it's ignored, and a shutdown hook is treated so specially that it's effectively a different kind of thread.

> src/java.base/share/classes/java/lang/Runtime.java line 174:
> 
>> 172:      * Uncaught exceptions are handled in shutdown hooks just as in any other thread,
>> 173:      * by invoking the {@link ThreadGroup#uncaughtException uncaughtException}
>> 174:      * method of the thread's {@link ThreadGroup} object. After the uncaught exception
> 
> Uncaught exception handling is a bit more complicated as there can be per-thread and default UHE set. I think it would be better to not mention ThreadGroup and instead just link to Thread#setDefaultUncaughtExceptionHandler.

I linked to the Thread.UncaughtExceptionHandler class, which details the whole process.

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

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

From smarks at openjdk.org  Thu Aug  4 03:09:09 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 4 Aug 2022 03:09:09 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v2]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <aL1GuBcZXspU6NuFBp4aJ3I7EGwJXyAQ1LHRkltS_io=.c32222e0-dc6a-4a50-a0c7-82272ee13d9a@github.com>

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Updates after conversation with Alan:
  - specify that starting a shutdown hook explicitly has an unspecified
    effect on the shutdown sequence
  - link Thread class doc to shutdown sequence
  - link to Thread.UncaughtExceptionHandler
  - clarify that only live non-daemon threads are significant
  - use "thread termination" to conform to the text in the Thread class
  - adjust line breaks and whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/4d7d6f73..b23a7321

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

  Stats: 53 lines in 2 files changed: 6 ins; 9 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

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

From jwaters at openjdk.org  Thu Aug  4 04:21:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 4 Aug 2022 04:21:08 GMT
Subject: RFR: 8291454: Missing check for JLI C runtime library in
 CoreLibraries.gmk
In-Reply-To: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
References: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
Message-ID: <XkNIbsaLONky2_8aYfcsRV8ywNXazLzJ2drSjaZzBJA=.76ccd521-b51c-4e2f-8f81-82952f489f8f@github.com>

On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect

Comment to keep thread alive

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

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

From shade at openjdk.org  Thu Aug  4 06:14:56 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 Aug 2022 06:14:56 GMT
Subject: RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
 [v3]
In-Reply-To: <XX_C2Cez7VS_JhulZTlsfQ8K-bGbY62ozFcYZL2z0bw=.ffcdefa2-16e1-42f9-acf6-1c24ecc0f9f1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
 <XX_C2Cez7VS_JhulZTlsfQ8K-bGbY62ozFcYZL2z0bw=.ffcdefa2-16e1-42f9-acf6-1c24ecc0f9f1@github.com>
Message-ID: <XJbOKpMYqNap7IRm87N6AeRHvtdNRjhrthBlH04q7l0=.f15980f4-ce1d-495d-9e24-20635b651a20@github.com>

On Wed, 3 Aug 2022 22:17:38 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
>> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
>> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
>> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nits from review comments

Marked as reviewed by shade (Reviewer).

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

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

From duke at openjdk.org  Thu Aug  4 06:29:10 2022
From: duke at openjdk.org (ScientificWare)
Date: Thu, 4 Aug 2022 06:29:10 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2]
In-Reply-To: <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
Message-ID: <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>

On Wed, 6 Jul 2022 23:56:33 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is tracked in JBS as
>> 
>> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
>> 
>> Unused imports in DTDBuider.java.
>> 
>>> **Remove unused imports from DTDBuilder.java**
>> 
>> Some imports are no more used.
>> 
>> - java.io.FileNotFoundException;
>> - java.io.BufferedInputStream;
>> - java.io.OutputStream;
>> - java.util.BitSet;
>> - java.util.StringTokenizer;
>> - java.util.Properties;
>> - java.util.zip.DeflaterOutputStream;
>> - java.util.zip.Deflater;
>> - java.net.URL;
>> 
>> https://github.com/scientificware/jdk/issues/4
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Remove unused imports.
>    
>    Some imports are no more used.
>    
>    - java.io.FileNotFoundException;
>    - java.io.BufferedInputStream;
>    - java.io.OutputStream;
>    - java.util.BitSet;
>    - java.util.StringTokenizer;
>    - java.util.Properties;
>    - java.util.zip.DeflaterOutputStream;
>    - java.util.zip.Deflater;
>    - java.net.URL;

Just waiting to be reviewed.

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

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

From alanb at openjdk.org  Thu Aug  4 06:54:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 06:54:04 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
Message-ID: <BTG8K2qKkppaJosnUKk-6fxObiWAE2rCtld-O2OzYxI=.ff96d2f8-9005-4e55-b0d4-d96bfa253d7c@github.com>

On Wed, 3 Aug 2022 10:21:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 
> 
> Mach5 tiers1-3 have been run without failure

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/159

From djelinski at openjdk.org  Thu Aug  4 06:59:58 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 4 Aug 2022 06:59:58 GMT
Subject: Integrated: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
In-Reply-To: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
References: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
Message-ID: <Y20iTC0pM_CJ7223R9Z4Q5336zGJbqaCj_JBIoFkTgc=.8436b1bc-62cd-499f-845a-667f818f0b1a@github.com>

On Wed, 3 Aug 2022 13:55:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the test to use the same locale as the tested code

This pull request has now been integrated.

Changeset: 4772354f
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4772354f4caf5eb314eda81217e5bc48a62d485b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8291825: java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if defaultLocale and defaultFormatLocale are different

Reviewed-by: naoto

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

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

From alanb at openjdk.org  Thu Aug  4 07:02:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 07:02:54 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
Message-ID: <mq-I-VeMYEPhT9vfR8Csg3eVNBOeHMfHrQwFWfWUw8c=.5f831a2b-e145-42bb-ab1b-38ddd953b322@github.com>

On Wed, 3 Aug 2022 10:21:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 
> 
> Mach5 tiers1-3 have been run without failure

The revert looks okay but it is concerning that the original change was not caught by a test. Are there tests that could have caught this?

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

PR: https://git.openjdk.org/jdk19/pull/159

From aph-open at littlepinkcloud.com  Thu Aug  4 08:51:01 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Thu, 4 Aug 2022 09:51:01 +0100
Subject: Coupling in ExtentLocal
In-Reply-To: <BCF4A922-6BD5-4308-B9D8-C80EA6A56040@oracle.com>
References: <CAKswmE58FR+GfLBEGQ6_3qhp1aFh=HqLXopTc0KFKpPwdPk30g@mail.gmail.com>
 <CAPs6153LT8WfE0xMamFuBJApJSOcGnSQnRVVE+RKnkb6eBZy=w@mail.gmail.com>
 <CAKswmE7ikJG_GA4hanweedkWYiPqTffj1tiJayp+0jBtHZWYmg@mail.gmail.com>
 <BCF4A922-6BD5-4308-B9D8-C80EA6A56040@oracle.com>
Message-ID: <7da05901-89ee-0bbe-110b-c8022d4526ca@littlepinkcloud.com>

On 7/29/22 21:37, Ron Pressler wrote:
> Yes, we are thinking about a "strong? TwR, but we?re busy with so many things so it might take a while. Until then, we might introduce a weaker, or less trustworthy version of ExtentLocals that uses the existing TwR and wouldn?t be used for critical things, but we think that it?s best to start incubation with just the lambda API and then see what problems are most common/annoying and how we can best address them.

One of the worst problems with using "weak" TWR for extent locals is that
ensuring the invariants with respect to structured concurrency is hard.
You end up with complex consistency checks that must be checked at runtime,
and are hard to test.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From alanb at openjdk.org  Thu Aug  4 09:57:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 09:57:00 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v2]
In-Reply-To: <aL1GuBcZXspU6NuFBp4aJ3I7EGwJXyAQ1LHRkltS_io=.c32222e0-dc6a-4a50-a0c7-82272ee13d9a@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <aL1GuBcZXspU6NuFBp4aJ3I7EGwJXyAQ1LHRkltS_io=.c32222e0-dc6a-4a50-a0c7-82272ee13d9a@github.com>
Message-ID: <dShHEBWoE4nCFIi8CgboLxQO4iqyDy68W03o4y59WKk=.37ad315b-09b5-4690-9178-c5794803e643@github.com>

On Thu, 4 Aug 2022 03:09:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Initial edits to addShutdownHook from Alex.
>> 
>> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates after conversation with Alan:
>   - specify that starting a shutdown hook explicitly has an unspecified
>     effect on the shutdown sequence
>   - link Thread class doc to shutdown sequence
>   - link to Thread.UncaughtExceptionHandler
>   - clarify that only live non-daemon threads are significant
>   - use "thread termination" to conform to the text in the Thread class
>   - adjust line breaks and whitespace

src/java.base/share/classes/java/lang/Thread.java line 101:

> 99:  * the shutdown sequence from commencing. Invoking the {@linkplain Runtime#exit(int)}
> 100:  * method will start the shutdown sequence regardless of whether non-daemon threads
> 101:  * are still running.

Future down, in the "Virtual threads" section we have "Virtual threads are daemon threads and so do not prevent the Java virtual machine from terminating". That will need to be updated too to say that it they do not prevent the shutdown sequence from commencing.

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

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

From alanb at openjdk.org  Thu Aug  4 10:03:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 10:03:13 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v2]
In-Reply-To: <Tt1qKHbWsU9d34DXh3GQVrCd5Y_zUrF82LlUUcATNuY=.c5795f86-f574-4321-83fa-6e7676b46726@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <pQzSrmh1t4uaLnFWSiBVchn1lYP3GpPtc7vptm3WGAM=.f32fb2c4-9a9a-424f-aa1a-1949cc45b41e@github.com>
 <Tt1qKHbWsU9d34DXh3GQVrCd5Y_zUrF82LlUUcATNuY=.c5795f86-f574-4321-83fa-6e7676b46726@github.com>
Message-ID: <Q8As9og51DtiaPdJkX7T7uAUXVCUH5q1H4-D4WGbeo0=.eaa73407-fccb-44b9-a51f-b98a1b92cf1f@github.com>

On Thu, 4 Aug 2022 02:51:03 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Runtime.java line 79:
>> 
>>> 77:  * terminate the JVM via the {@link #halt halt} method.
>>> 78:  * <h2><a id="termination">Virtual Machine Termination</a></h2>
>>> 79:  * When the JVM terminates, all threads (daemon, non-daemon, and shutdown hooks) are immediately
>> 
>> "daemon, non-daemon, and shutdown hooks" reads like there are 3 kinds of threads. I would be tempted to drop "shutdown hooks" from this list or else phrase it as "all shutdown hooks and all other threads".
>
> Alex and I discussed this and we felt that it was important to call out all three "kinds" of threads explicitly. Earlier versions of the text implied that no non-daemon threads were running at the time the VM terminated, which might not be true. Earlier text also implied that shutdown hooks had terminated before the VM terminated, but this isn't necessarily true if somebody calls halt(). Yes, a shutdown hook has a daemon/non-daemon bit, but effectively it's ignored, and a shutdown hook is treated so specially that it's effectively a different kind of thread.

I understand but as currently worded the reader may wonder what Thread::isDaemon might return when it invoked on Thread that is a shutdown hook. I think the best I can suggest is to replace "daemon, non-daemon, and shutdown hooks" with "shutdown hooks and other daemon and non-daemon threads".

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

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

From lancea at openjdk.org  Thu Aug  4 10:57:08 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 4 Aug 2022 10:57:08 GMT
Subject: [jdk19] RFR: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <mq-I-VeMYEPhT9vfR8Csg3eVNBOeHMfHrQwFWfWUw8c=.5f831a2b-e145-42bb-ab1b-38ddd953b322@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
 <mq-I-VeMYEPhT9vfR8Csg3eVNBOeHMfHrQwFWfWUw8c=.5f831a2b-e145-42bb-ab1b-38ddd953b322@github.com>
Message-ID: <_glHovs19czE_D_DOH5xhDGjT275cKusmOGPne9HMpM=.d2285dd3-962a-4451-a35d-6df1513c24f1@github.com>

On Thu, 4 Aug 2022 06:59:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The revert looks okay but it is concerning that the original change was not caught by a test. Are there tests that could have caught this?

Not that I am aware of.

per open/src/java.base/share/native/libzip/zlib/patches/ChangeLog_java

JDK-8191918  modifies the changes made in JDK-8184306 to use the official zlib repo fix see#305/#f969409

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

PR: https://git.openjdk.org/jdk19/pull/159

From plevart at openjdk.org  Thu Aug  4 11:06:40 2022
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 4 Aug 2022 11:06:40 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual
 thread(s)
Message-ID: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>

This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

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

Commit messages:
 - new internal CarrierThreadLocal as a base for TerminatingThreadLocal

Changes: https://git.openjdk.org/jdk/pull/9743/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291897
  Stats: 255 lines in 9 files changed: 193 ins; 9 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/9743.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9743/head:pull/9743

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

From dholmes at openjdk.org  Thu Aug  4 12:30:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Aug 2022 12:30:58 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v3]
In-Reply-To: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
 <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
 <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>
Message-ID: <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>

On Tue, 2 Aug 2022 12:45:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Seems odd to display as major:minor when it is stored as minor:major
>
> I think it seems more natural to display the major version first, but I can change it if you prefer.

I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value.

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

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

From coleenp at openjdk.org  Thu Aug  4 12:38:55 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Aug 2022 12:38:55 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v3]
In-Reply-To: <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
 <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
 <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>
 <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>
Message-ID: <QpcWALqdYTzrdaSZAlDCH09HlYIie3soBS7SRgIUFK4=.f89b2ea2-89ec-4644-913c-0d7a2bef51d3@github.com>

On Thu, 4 Aug 2022 12:28:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it seems more natural to display the major version first, but I can change it if you prefer.
>
> I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value.

Do humans read this or computers?  A human would want major:minor because that would make more sense.  Isn't this a test?  Just a drive by comment.

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

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

From hseigel at openjdk.org  Thu Aug  4 12:51:33 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 4 Aug 2022 12:51:33 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v4]
In-Reply-To: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
Message-ID: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com>

> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
> 
> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  change test to display minor_verion:major_version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9688/files
  - new: https://git.openjdk.org/jdk/pull/9688/files/941971dc..b71a79a4

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

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

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

From hseigel at openjdk.org  Thu Aug  4 12:51:33 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 4 Aug 2022 12:51:33 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v4]
In-Reply-To: <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
 <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
 <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>
 <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>
Message-ID: <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com>

On Thu, 4 Aug 2022 12:28:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it seems more natural to display the major version first, but I can change it if you prefer.
>
> I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value.

@dholmes-ora Please see latest commit that changes the test to display minor:major.

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

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

From dholmes at openjdk.org  Thu Aug  4 13:09:17 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Aug 2022 13:09:17 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v4]
In-Reply-To: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com>
Message-ID: <jdFxYRMJucZsSaRDgH1Zw4rxuIPDxslhlwifQCH6AYI=.eb11113f-1ccb-4404-ba31-54c92c36039a@github.com>

On Thu, 4 Aug 2022 12:51:33 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change test to display minor_verion:major_version

Marked as reviewed by dholmes (Reviewer).

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

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

From dholmes at openjdk.org  Thu Aug  4 13:09:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Aug 2022 13:09:18 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v4]
In-Reply-To: <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <PVbVick-2gkyYboHfYFebG5UhlCCVfUratsXTiFplQ4=.af01c41c-3bce-4be3-9beb-7de89aa3932a@github.com>
 <MNG7Ado90zE-RtO-OWxlAzTOYf5TBEZGBIvVxrpCu_o=.16558028-77ba-4076-a6f7-268802cf2630@github.com>
 <N0zPWsUuhUvjde4SJF_Ac-MzzigGUkIH1RVIgSEFWgs=.8ed8fe02-4527-420f-983a-addbe3c9d38e@github.com>
 <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com>
 <XXlo4g_x_wgeCqcL0JyrqXzoixkLQnnZRNqw8L7m4L0=.34695840-c61f-4116-b661-9627f4a4c0fa@github.com>
 <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com>
Message-ID: <uSLnU8jL3WUrohLZrSl_1ikm0D8mh2RwXC3KEH_2zQM=.39db4fb8-b3c1-4af8-9e77-42a49a3e8dbf@github.com>

On Thu, 4 Aug 2022 12:47:13 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value.
>
> @dholmes-ora Please see latest commit that changes the test to display minor:major.

Latest change is good.

@coleenp this is for humans reading failed test output. If it reports "expected 0:1 but got 1:1" then the natural tendency would be to look for an issue in the upper word, when in fact the problem is in the lower word.

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

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

From hseigel at openjdk.org  Thu Aug  4 13:14:32 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 4 Aug 2022 13:14:32 GMT
Subject: RFR: 8291360: Create entry points to expose low-level class file
 information [v4]
In-Reply-To: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
 <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com>
Message-ID: <YzbXqEqKG6oQ1duBsH2sYoSwxG8eJHQZ1RKxzVJ5hxg=.4ad2451f-ece8-4c4d-8883-470d88449e34@github.com>

On Thu, 4 Aug 2022 12:51:33 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
>> 
>> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change test to display minor_verion:major_version

Thanks Roger, David, Joe, and Coleen for your comments and reviews!

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

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

From hseigel at openjdk.org  Thu Aug  4 13:15:57 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 4 Aug 2022 13:15:57 GMT
Subject: Integrated: 8291360: Create entry points to expose low-level class
 file information
In-Reply-To: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
References: <JtgPMvSWG3afXNg06YI7XFajtjHMK3-miZPFW6XghFk=.c4ba7419-2359-42eb-9ee5-3376063843ec@github.com>
Message-ID: <J88GrgZfFEB_PRTfZbjNh5WIQh9MUi_--YmuLN2ggyA=.a1c6d6c3-fff7-4a52-8659-68f5012ecd7b@github.com>

On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to fix JDK-8291360.  This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class.  The new entry points return the current class's class file version and its raw access flags.
> 
> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64.  Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: a3040fcc
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3040fcc2baa48c19d9525b3539863a71fa5781d
Stats:     812 lines in 9 files changed: 811 ins; 0 del; 1 mod

8291360: Create entry points to expose low-level class file information

Reviewed-by: dholmes, rriggs

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

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

From plevart at openjdk.org  Thu Aug  4 13:29:05 2022
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 4 Aug 2022 13:29:05 GMT
Subject: Integrated: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
In-Reply-To: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
References: <ymBgvSxB5OEKktRcpX2Me6jR4x-4vLvG5cqiwseSe3k=.9694e3a4-0325-4e2a-bc4f-1a36bdf3ecd1@github.com>
Message-ID: <BoGW2itp8vNzZXX_VaxtXlNG20Slrt5IjBScl8YM1mQ=.8c13aa6a-2cac-4445-a0fe-e4c69bd67791@github.com>

On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods:
> - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined
> - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah.

This pull request has now been integrated.

Changeset: d4a795d7
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a
Stats:     96 lines in 1 file changed: 69 ins; 11 del; 16 mod

8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs

Reviewed-by: rkennke, shade

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

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

From plevart at openjdk.org  Thu Aug  4 13:46:41 2022
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 4 Aug 2022 13:46:41 GMT
Subject: [jdk19] RFR: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
Message-ID: <A1oSFiGyiyaJlE4RGxcojwIlZjgLiRVZoyncWdskHq8=.ec013beb-80df-4f43-aeca-dd95ef430a8f@github.com>

Hi all,

    This pull request contains a backport of commit [d4a795d7](https://github.com/openjdk/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

    The commit being backported was authored by Peter Levart on 4 Aug 2022 and was reviewed by Roman Kennke and Aleksey Shipilev.

    Thanks!

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

Commit messages:
 - Backport d4a795d75aef8d787934f5c05e146c61138a408a

Changes: https://git.openjdk.org/jdk19/pull/162/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=162&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283276
  Stats: 96 lines in 1 file changed: 69 ins; 11 del; 16 mod
  Patch: https://git.openjdk.org/jdk19/pull/162.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/162/head:pull/162

PR: https://git.openjdk.org/jdk19/pull/162

From duke at openjdk.org  Thu Aug  4 15:20:13 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 4 Aug 2022 15:20:13 GMT
Subject: Integrated: 8288327: Executable.hasRealParameterData should not be
 volatile
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <GbX1v7Bp9nin5smnYpSYKRIbVDvSzpvItud3w-4wr34=.63936486-cfa9-4cc5-9d8a-3ed74977299a@github.com>

On Mon, 13 Jun 2022 18:42:24 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

This pull request has now been integrated.

Changeset: aa557b9b
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa557b9b01571d7614f54d341c5cd8bf36cdacee
Stats:     48 lines in 1 file changed: 13 ins; 19 del; 16 mod

8288327: Executable.hasRealParameterData should not be volatile

Reviewed-by: plevart

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

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

From jwaters at openjdk.org  Thu Aug  4 16:55:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 4 Aug 2022 16:55:37 GMT
Subject: RFR: 8291917: [WINDOWS] Dump error diagnostics when runtime libraries
 fail to load
Message-ID: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>

Please review a small patch for dumping the failure reason when the MSVCRT libraries or the JVM fails to load on Windows, which have been very helpful in my personal fork of the JDK so far This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.

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

Commit messages:
 - LoadLibrary checks should explicitly use NULL
 - Dump error (if any) when libraries fail to load
 - Prettify DLL_ERROR4

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

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

From plevart at openjdk.org  Thu Aug  4 16:59:01 2022
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 4 Aug 2022 16:59:01 GMT
Subject: [jdk19] Integrated: 8283276:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
In-Reply-To: <A1oSFiGyiyaJlE4RGxcojwIlZjgLiRVZoyncWdskHq8=.ec013beb-80df-4f43-aeca-dd95ef430a8f@github.com>
References: <A1oSFiGyiyaJlE4RGxcojwIlZjgLiRVZoyncWdskHq8=.ec013beb-80df-4f43-aeca-dd95ef430a8f@github.com>
Message-ID: <_NnUfrOVkjif4qtYX4iAIhnKQK_9FLWd_28UJFtowOg=.dd7bdaf4-6c0b-4329-9f66-0437386facd8@github.com>

On Thu, 4 Aug 2022 13:38:08 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [d4a795d7](https://github.com/openjdk/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Peter Levart on 4 Aug 2022 and was reviewed by Roman Kennke and Aleksey Shipilev.
> 
>     Thanks!

This pull request has now been integrated.

Changeset: 4b3dfe1d
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/4b3dfe1d22f7fed8a408ee50343d52cf1ac481ef
Stats:     96 lines in 1 file changed: 69 ins; 11 del; 16 mod

8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs

Backport-of: d4a795d75aef8d787934f5c05e146c61138a408a

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

PR: https://git.openjdk.org/jdk19/pull/162

From akasko at openjdk.org  Thu Aug  4 17:10:16 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Thu, 4 Aug 2022 17:10:16 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
Message-ID: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>

This change splits existing single Feature `DefaultFeature` into 3 different feautures:

 - `DefaultFeature_Files`: application and runtime files
 - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
 - `DefaultFeature_FileAssociations`: File Association components

These 3 Features are nested under the existing top-level Feature.

Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:


warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.


This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.

To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.

It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.

Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.

It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).

It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.

Testing:

 - `WinFeaturesTest` that installs and checks Features one by one
 - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

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

Commit messages:
 - 8291915: jpackage: use multiple Features in MSI installer

Changes: https://git.openjdk.org/jdk/pull/9751/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9751&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291915
  Stats: 186 lines in 7 files changed: 167 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9751/head:pull/9751

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

From jwaters at openjdk.org  Thu Aug  4 17:40:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 4 Aug 2022 17:40:22 GMT
Subject: RFR: 8291917: Dump error diagnostics when runtime libraries fail
 to load (win) [v2]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <nLkE1XGK6d23kTi_mcJie2tDk53VsYab5k_QgfuPe9U=.a82af970-954c-49d6-9a55-9c046695f17c@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the JVM fails to load on Windows, which have been very helpful in my personal fork of the JDK so far This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Introduce warning when system error cannot be determined

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/2bab51eb..769266a3

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

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

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

From asemenyuk at openjdk.org  Thu Aug  4 17:40:47 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 4 Aug 2022 17:40:47 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <vCr33FYyp-bjdzXuanNOx4gT8ZT09llcBTcXOWPUGuA=.cb74f858-aad6-4a5f-90a7-935e5d05e3f2@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 491:

> 489:             xml.writeAttribute("WorkingDirectory", INSTALLDIR.toString());
> 490:             xml.writeAttribute("Advertise", "no");
> 491:             xml.writeAttribute("Target", "[ARPMAINLAUNCHERLOCATION]");

I don't think you can replace `launcherPath` with `[ARPMAINLAUNCHERLOCATION]`. `launcherPath` can reference any application launcher, i.e. it can be the main or one of the additional app launchers.

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

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

From jwaters at openjdk.org  Thu Aug  4 17:42:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 4 Aug 2022 17:42:45 GMT
Subject: RFR: 8291917: Dump error diagnostics when runtime libraries fail
 to load (win) [v3]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the JVM fails to load on Windows, which have been very helpful in my personal fork of the JDK so far This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Missing spacing between errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/769266a3..3bd53488

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

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

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

From duke at openjdk.org  Thu Aug  4 17:49:45 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 4 Aug 2022 17:49:45 GMT
Subject: RFR: JDK-8290836 Improve test coverage for XPath functions: String
 Functions
Message-ID: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>

Improve test coverage for XPath functions: [JDK-8290836](https://bugs.openjdk.org/browse/JDK-8290836), [JDK-8290837](https://bugs.openjdk.org/browse/JDK-8290837), [JDK-8290838](https://bugs.openjdk.org/browse/JDK-8290838).

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

Commit messages:
 - Added exception test cases for node set functions.
 - Added exception tests.
 - Extracted common test codes for xpath exp eval to a new function.
 - Changes for String, Bollean and Number Functions

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

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

From asemenyuk at openjdk.org  Thu Aug  4 18:12:41 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 4 Aug 2022 18:12:41 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <WoVg1W3GhcpLRAtetabSpTcyjpfhqSeGfaJ-TbZY29w=.654d44dc-1727-4ea3-bdea-814a28ff9a92@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

ARPMAINLAUNCHERLOCATION property name mimics standard MSI property names starting with ARP (Add Remove Programs) prefix. I don't see how it is related to these properties. Let's come up with a different name. No `ARP` prefix would be sufficient.

test/jdk/tools/jpackage/windows/WinFeaturesTest.java line 73:

> 71:                         TKit.assertFalse(Files.exists(launcherPath), launcherPath.toString());
> 72:                     }
> 73:                 });

I'd move verification of not installed feature into PackageTest/WindowsHelper. It would be good to have API that will allow getting the list of files belonging to the named feature. This will allow strict verification of installed/not installed features inside of the testing framework without exposing this functionality to tests. In this PR the testing framework verifies that a specific feature is installed, but doesn't verify if a specific feature is not installed. It can be an overkill for one PR, a follow-up CR can be filed and resolved in a separate PR.

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

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

From akasko at openjdk.org  Thu Aug  4 18:23:11 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Thu, 4 Aug 2022 18:23:11 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label
Message-ID: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>

This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).

Note, non-EN l10n values were filled using auto-translator and may need to be corrected.

To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.

Testing:

 - [x] ran `FileAssociationsTest` with `install` enabled

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

Commit messages:
 - 8291924: jpackage: l10n for Windows context menu label

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

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

From duke at openjdk.org  Thu Aug  4 18:53:18 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 4 Aug 2022 18:53:18 GMT
Subject: Integrated: 8288377: [REDO] DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <Gi8R81a7_kywu2qVCiCT0OqCF6FOfUTKj97N0Xy9KC0=.4b1e0f69-04ef-46c8-9984-71f99f10ab35@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

This pull request has now been integrated.

Changeset: 3c325641
Author:    Gaurav Chaudhari <deigue at hotmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c3256414f7df049cdd6c8519fbcea0d818a1a33
Stats:     126 lines in 2 files changed: 86 ins; 28 del; 12 mod

8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable

Reviewed-by: naoto

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

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

From holo3146 at gmail.com  Thu Aug  4 19:35:33 2022
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Thu, 4 Aug 2022 22:35:33 +0300
Subject: Coupling in ExtentLocal
In-Reply-To: <7da05901-89ee-0bbe-110b-c8022d4526ca@littlepinkcloud.com>
References: <CAKswmE58FR+GfLBEGQ6_3qhp1aFh=HqLXopTc0KFKpPwdPk30g@mail.gmail.com>
 <CAPs6153LT8WfE0xMamFuBJApJSOcGnSQnRVVE+RKnkb6eBZy=w@mail.gmail.com>
 <CAKswmE7ikJG_GA4hanweedkWYiPqTffj1tiJayp+0jBtHZWYmg@mail.gmail.com>
 <BCF4A922-6BD5-4308-B9D8-C80EA6A56040@oracle.com>
 <7da05901-89ee-0bbe-110b-c8022d4526ca@littlepinkcloud.com>
Message-ID: <CAKswmE68NDCTPCY_cNnQNAwzBkXR1dM0PNfOjSk3PV0a9Poa-A@mail.gmail.com>

It looks pretty inconsistent to have the API of the structured concurrency
and of ExtentLocal have different design, especially when it seems like the
2 APIs have the same base assumptions.

>From my understanding those 2 features are meant for each other. I actually
agree that allowing ?weak? TwR for ExtentLocals is probably a bad idea, but
I also believe the same for structured concurrency:

    void foo() {
        var scope = new StructuredTaskScope.ShutdownOnFailure();
        var scope1 = new StructuredTaskScope.ShutdownOnFailure();

        scope.close();
        scope1.close();
    }

This should fail on compile time.

This is less important for the incubator, but for the preview I do think it
is important to prevent weird bugs when people misusing the feature.
For example, I can see someone without understanding of structured
concurrency writing the following:

// abstraction of a calculation on "int[]" that can be partitioned and
then aggregated into a single result// contains "int set/setCount()"
for the count of partitions, a method "void calcPart(int[] lst, int
partNumber)", "void aggregateParts()" and "int getResult()"public
interface PartitiableAction { ... }
...public static void calcAtOnce(Collection<PartitiableAction>
actions, int[] input) {
   var scopes = new HashMap<PartitiableAction,
StructuredTaskScope.ShutdownOnFailure>();
   // start a scope for each action
   for (var action : actions) {
       var scope = new StructuredTaskScope.ShutdownOnFailure();
        scopes.put(action, scope);
         // new thread for each part of the calculation
        for (var j = 0; j < action.getCount(); j++)  scope.fork(() =>
 action.calcPart(input, j));
   }

   // !! Undefined behavior !!
   for (var action : actions) {
         var scope = scopes.get(action);
         scope.join();
         action.aggregateParts();
         scope.close();
    }

}

Some implementations of Collection that will always fail, some will always
succeed, and some implementations (like HashSet) may be non-deterministic.
For the uninformed this method makes sense, for each PartitiableAction I
create some kind of a new ?Executor? that everyone is talking about, if one
of the parts fails, the whole calculation of this specific PartitiableAction
will stop running, and I am waiting for everything to end.
------------------------------

I can write a PoC compiler plugin such that classes with @StrongTwR
annotation can only be assigned inside TwR (unless they are also the return
value) (I will probably do it tomorrow and send a link to it in a follow up
mail if people are interested)

On Thu, Aug 4, 2022 at 11:51 AM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 7/29/22 21:37, Ron Pressler wrote:
> > Yes, we are thinking about a "strong? TwR, but we?re busy with so many
> things so it might take a while. Until then, we might introduce a weaker,
> or less trustworthy version of ExtentLocals that uses the existing TwR and
> wouldn?t be used for critical things, but we think that it?s best to start
> incubation with just the lambda API and then see what problems are most
> common/annoying and how we can best address them.
>
> One of the worst problems with using "weak" TWR for extent locals is that
> ensuring the invariants with respect to structured concurrency is hard.
> You end up with complex consistency checks that must be checked at runtime,
> and are hard to test.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>


-- 
Holo The Wise Wolf Of Yoitsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220804/848d6f22/attachment.htm>

From alanb at openjdk.org  Thu Aug  4 19:40:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 19:40:34 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>

On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

I did a quick pass over this and it looks good. Adding CarrierThreadLocal is a good idea and as it allows the use-sites to be revert/cleaned up. Just a few minor comments so far.

src/java.base/share/classes/sun/nio/ch/Util.java line 233:

> 231:         }
> 232: 
> 233:         BufferCache cache = bufferCache.get();

I assume JLA is no longer needed.

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40:

> 38:  * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java
> 39:  * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal
> 40:  */

If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. 

You might want to add the bugId to the `@bug` list too.

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

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

From akasko at openjdk.org  Thu Aug  4 20:34:00 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Thu, 4 Aug 2022 20:34:00 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <P8IYLTL6D1NdxQCXsV4Bm-LTFXCdgyL9nDrz-PERxLU=.fee27e8c-0925-4762-bd6c-26bb1f870bf0@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

Alexey, thanks for your comments! I think the point on multiple launchers is a serious issue, for some reason I've assumed that these references are only done for the main launcher. I will experiment with multiple launchers and will update the patch.

A number of more general questions on multiple Features support:

1. Would the following logic be acceptable:

 - "Files" feature is expected to be installed always (should have `Absent="disallow"`)
 - all other features ("Shortcuts", "FileAssociations", prospective "RegistryEntries") are independent of each other, but expected to be installed only when "Files" is installed too
 - while `Absent="disallow"` will enforce "Files" selection in prospective FeatureTree GUI, it won't enforce it in CLI - any set of Features can be selected for installation with `ADDLOCAL`; can we assume, that situation when "Files" is not installed is considered "unsupported" and doesn't need to be taken into consideration in the impl or covered with tests?

2. Currently "Files" feature is nested under top-level feature. Would it be more appropriate to move "Files" contents into top-level feature?

3. Besides actual FS files, currently "Files" feature contains a "crm_rf" (`util:RemoveFolderEx`) component. Should this component be part of "Files" or moved to a separate feature ("Uninstall Actions" or something like this)?

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

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

From asemenyuk at openjdk.org  Thu Aug  4 20:34:16 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 4 Aug 2022 20:34:16 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <ZZVXvgDBcLzp9QGdLhJPdAvGUg9Bm72Ymn6Bdb5GawE=.5c4638d5-3d3e-4d4a-9df9-383b5cfc8279@github.com>

On Thu, 4 Aug 2022 18:10:18 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 359:

> 357:     }
> 358: 
> 359:     public static String queryRegistryValue(String keyPath, String valueName) {

It should be sufficient to make it package private, not public.

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

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

From naoto at openjdk.org  Thu Aug  4 20:40:35 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Aug 2022 20:40:35 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <0HBXdIMCoFjADg_SeDrxYedTBbgs-Zf15oS4AAt9P0w=.f2a0acaa-8162-4da6-bcf2-86966192ffd6@github.com>

On Thu, 4 Aug 2022 18:10:18 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

As to the l10n files, no need to provide those. Providing the English resource is just fine. L10n will pick them up in the later translation process.

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

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

From asemenyuk at openjdk.org  Thu Aug  4 20:52:17 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 4 Aug 2022 20:52:17 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <dVbo8ODA-B9iKeJxC40KATvJpwxrY2UlMFXSpBumKdM=.71d9031e-06d9-4086-bada-11e4b8f15a6f@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

I agree "Files" feature should be marked mandatory for installation. Other features are optional.
I don't have a preference whether "Files" should be a top-level feature or nested. Up to you.
"crm_rf" component is mandatory and must be always installed. This is the only requirement I can think of. It can be in "Files" feature or in a separate one. Up to you.

UPD: We can control if "Files" feature is top-level or nested through WiX variables and users can override it in custom `overrides.wxi`. Just like this is done for `JpAllowDowngrades` and `JpAllowUpgrades`.

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

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

From asemenyuk at openjdk.org  Thu Aug  4 20:55:46 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 4 Aug 2022 20:55:46 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <gUDPJg_LdaTzhEE5aWvu5W-ZmxZJgKj6k0nwiydegA0=.ae46c513-e30e-4a5b-b26d-bfcbdc7d142c@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

FYI: AddLShortcutTest test covers additional launchers with optional shortcuts.

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

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

From dcubed at openjdk.org  Thu Aug  4 22:36:32 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Aug 2022 22:36:32 GMT
Subject: RFR: 8291941: ProblemList
 java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all
Message-ID: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>

A trivial fix to ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all.

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

Commit messages:
 - 8291941: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all

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

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

From dholmes at openjdk.org  Thu Aug  4 22:36:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Aug 2022 22:36:33 GMT
Subject: RFR: 8291941: ProblemList
 java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all
In-Reply-To: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>
References: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>
Message-ID: <1KDUaU2N5ix5GHA6WtE7uVoHlQLMfMcGGtkOHtsXLgk=.2ca35a81-48fd-4eff-aff5-227b2f300ca7@github.com>

On Thu, 4 Aug 2022 22:23:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all.

Marked as reviewed by dholmes (Reviewer).

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

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

From dcubed at openjdk.org  Thu Aug  4 22:36:33 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Aug 2022 22:36:33 GMT
Subject: RFR: 8291941: ProblemList
 java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all
In-Reply-To: <1KDUaU2N5ix5GHA6WtE7uVoHlQLMfMcGGtkOHtsXLgk=.2ca35a81-48fd-4eff-aff5-227b2f300ca7@github.com>
References: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>
 <1KDUaU2N5ix5GHA6WtE7uVoHlQLMfMcGGtkOHtsXLgk=.2ca35a81-48fd-4eff-aff5-227b2f300ca7@github.com>
Message-ID: <5rgaaHH6WJDHWzJKHCW7ATCXbzkE5O8fP6Fgd6KB7gs=.1a5c4073-e4a1-4d7c-9213-e1df6a0bae2c@github.com>

On Thu, 4 Aug 2022 22:28:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all.
>
> Marked as reviewed by dholmes (Reviewer).

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

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

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

From dcubed at openjdk.org  Thu Aug  4 22:53:41 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Aug 2022 22:53:41 GMT
Subject: Integrated: 8291941: ProblemList
 java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all
In-Reply-To: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>
References: <xE3yKIa087L5zqLxkWDmuXSOlVDEH37QBBy61zutxnM=.878d4bf6-54a8-4723-8f36-8ae3a6c94943@github.com>
Message-ID: <7hZuQgqg0LbM1SWP-ORULXHZaqtcnavwENPWtdtb6Yo=.e81f80bf-a8c3-495f-83fe-6df5a805c561@github.com>

On Thu, 4 Aug 2022 22:23:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all.

This pull request has now been integrated.

Changeset: 6e6c64c6
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e6c64c6f6f5bd2b787071f847399f933936e0ed
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8291941: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java on linux-all

Reviewed-by: dholmes

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

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

From joehw at openjdk.org  Fri Aug  5 00:40:49 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 5 Aug 2022 00:40:49 GMT
Subject: RFR: JDK-8290836 Improve test coverage for XPath functions: String
 Functions
In-Reply-To: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
References: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
Message-ID: <yPODqTNRb7h9Lxm4O5Bq-X2JeOPdpc6VvTsLS4Gro8c=.34ba99cb-4174-4e86-95d5-4eb979603453@github.com>

On Thu, 4 Aug 2022 17:40:43 GMT, Bill Huang <duke at openjdk.org> wrote:

> Improve test coverage for XPath functions: [JDK-8290836](https://bugs.openjdk.org/browse/JDK-8290836), [JDK-8290837](https://bugs.openjdk.org/browse/JDK-8290837), [JDK-8290838](https://bugs.openjdk.org/browse/JDK-8290838).

Overall, nice set of tests!

I see you've covering three issues, sth. I don't have experience with, so let's see what happens. It might be that the tests have different bug id associated with them, not much of an issue as this is a test enhancement.

See comments below.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathBooleanFnTest.java line 96:

> 94:     /*
> 95:      * DataProvider for testing TransformerException being thrown on
> 96:      * invalid number function usage.

I think you meant XPathExpressionException instead of TransformerException.

Typo: s/number/boolean

This comment applies to other occurrences as well.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathBooleanFnTest.java line 102:

> 100:     @DataProvider(name = "exceptionExpTestCases")
> 101:     public Object[][] getExceptionExp() {
> 102:         return new Object[][]{

Applies to DataProviders for exception testing: would be good to add some notes about the data, e.g. why they are invalid.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathBooleanFnTest.java line 130:

> 128:      */
> 129:     @Test(dataProvider = "exceptionExpTestCases", expectedExceptions =
> 130:             XPathExpressionException.class)

expectedExceptions is fine in this case. But there's a preference in using assertThrows in general. I'll leave it to you to decide.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathNumberFnTest.java line 144:

> 142:     @Test(dataProvider = "numberExpTestCases")
> 143:     void testNumberFn(String exp, double expected) throws Exception {
> 144:         testExp(doc, exp, expected, Double.class);

Besides Double, Integer and Long are also supported. It's ok though as the focus here is on the XPath expressions. If you want to add a few cases, that would be good too.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathTestBase.java line 82:

> 80:             + "            <State>The State</State>"
> 81:             + "        </Address>"
> 82:             + "        <Age>0</Age>"

I don't see any issue in the test cases themselves. But the ages being 0, 1, -1 makes it slightly less readable because they can be confused with the number of nodes in the nodeset, even number(true()) as that also returns 1. It could be sth. that leads to mistakes. I would set the ages > 1, or actually greater than the number of nodes possibly returned.

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

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

From alanb at openjdk.org  Fri Aug  5 06:37:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 06:37:50 GMT
Subject: RFR: 8291916: Unexpected output on Arabic Windows command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <Iv2XVR3LT2ZJOX-XPInyizqaAH2tB8EgA_UG_CYfkCQ=.dab3684a-90e6-4257-9034-5717f9b195d9@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

IBM860 is Portuguese, IBM861 is Icelandic, IBM863 seems to be Candian French. So I think this is adding more than just Arabic charsets, it's really about expanding the set of configurations support on Windows I think.

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

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

From aturbanov at openjdk.org  Fri Aug  5 07:02:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 5 Aug 2022 07:02:42 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent in
 java.base
Message-ID: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>

I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
It's makes code a bit easier to read.
Noticing negation before long chain of method calls is hard.

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

Commit messages:
 - [PATCH] Use Optional.isEmpty instead of !Optional.isPresent in java.base

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

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

From jpai at openjdk.org  Fri Aug  5 07:44:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Aug 2022 07:44:00 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent
 in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <RR-vGKc2iHIhw_e5wluV852ZxehAJ5B-Tpf3VcYGuYw=.8f77bd0d-038d-4b37-8cf2-b57a2d82a136@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

The changes look fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From alanb at openjdk.org  Fri Aug  5 07:49:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 07:49:52 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent
 in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <0DDmv1Q58HVcv8Ncq5zK9aqle0-JgL7ae_V739vUPro=.9274e521-bc6f-4c9b-99db-a6498d3b3753@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

Looks good. The isEmpty was added in Java 11 so I think most (if not all) of these pre-date this method.

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

Marked as reviewed by alanb (Reviewer).

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

From jpai at openjdk.org  Fri Aug  5 07:58:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Aug 2022 07:58:48 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2]
In-Reply-To: <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
 <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>
Message-ID: <daorXu_NRyh6_DWKilgiwi3BJTB-vYOFcu7jhEpjRxg=.22750241-e53d-410b-9c83-4051b16ce644@github.com>

On Thu, 4 Aug 2022 06:25:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Remove unused imports.
>>    
>>    Some imports are no more used.
>>    
>>    - java.io.FileNotFoundException;
>>    - java.io.BufferedInputStream;
>>    - java.io.OutputStream;
>>    - java.util.BitSet;
>>    - java.util.StringTokenizer;
>>    - java.util.Properties;
>>    - java.util.zip.DeflaterOutputStream;
>>    - java.util.zip.Deflater;
>>    - java.net.URL;
>
> Just waiting to be reviewed.

Hello @scientificware, what you propose here, I think looks fine. Additionally can you also update the copyright years on this file from `Copyright (c) 1998, 2020,` to `Copyright (c) 1998, 2022,`?

I see that the changed file resides at `make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java` and I think this needs to be reviewed by the build team. @magicus, is it OK if I re-add the `build` label for this PR?

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

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

From duke at openjdk.org  Fri Aug  5 08:59:00 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 5 Aug 2022 08:59:00 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
Message-ID: <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>

> This is tracked in JBS as
> 
> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
> 
> Unused imports in DTDBuider.java.
> 
>> **Remove unused imports from DTDBuilder.java**
> 
> Some imports are no more used.
> 
> - java.io.FileNotFoundException;
> - java.io.BufferedInputStream;
> - java.io.OutputStream;
> - java.util.BitSet;
> - java.util.StringTokenizer;
> - java.util.Properties;
> - java.util.zip.DeflaterOutputStream;
> - java.util.zip.Deflater;
> - java.net.URL;
> 
> https://github.com/scientificware/jdk/issues/4

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

 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
 - Remove unused imports.
   
   Some imports are no more used.
   
   - java.io.FileNotFoundException;
   - java.io.BufferedInputStream;
   - java.io.OutputStream;
   - java.util.BitSet;
   - java.util.StringTokenizer;
   - java.util.Properties;
   - java.util.zip.DeflaterOutputStream;
   - java.util.zip.Deflater;
   - java.net.URL;

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9360/files
  - new: https://git.openjdk.org/jdk/pull/9360/files/6d097e77..ea243462

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

  Stats: 109079 lines in 2656 files changed: 58161 ins; 33308 del; 17610 mod
  Patch: https://git.openjdk.org/jdk/pull/9360.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9360/head:pull/9360

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

From duke at openjdk.org  Fri Aug  5 09:06:55 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 5 Aug 2022 09:06:55 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2]
In-Reply-To: <daorXu_NRyh6_DWKilgiwi3BJTB-vYOFcu7jhEpjRxg=.22750241-e53d-410b-9c83-4051b16ce644@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
 <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>
 <daorXu_NRyh6_DWKilgiwi3BJTB-vYOFcu7jhEpjRxg=.22750241-e53d-410b-9c83-4051b16ce644@github.com>
Message-ID: <uChH4TsDs7SA5xbTBSfrzP4Rlk7ghHiKAOzSJ15jzgY=.d30e91a0-df94-45a0-baa8-9a7c548ca213@github.com>

On Fri, 5 Aug 2022 07:56:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Just waiting to be reviewed.
>
> Hello @scientificware, what you propose here, I think looks fine. Additionally can you also update the copyright years on this file from `Copyright (c) 1998, 2020,` to `Copyright (c) 1998, 2022,`?
> 
> I see that the changed file resides at `make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java` and I think this needs to be reviewed by the build team. @magicus, is it OK if I re-add the `build` label for this PR?

Hello @jaikiran, the copyright years were updated by a previous commit.

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

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

From plevart at openjdk.org  Fri Aug  5 09:43:46 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:43:46 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
Message-ID: <Blmz01MMivZFrWFKuOa-SJpqnNUHhaQJCLXe5T7E2NQ=.1a49b007-1d30-4a09-8688-df7335c4e123@github.com>

On Thu, 4 Aug 2022 15:54:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
>> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
>> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
>> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.
>
> src/java.base/share/classes/sun/nio/ch/Util.java line 233:
> 
>> 231:         }
>> 232: 
>> 233:         BufferCache cache = bufferCache.get();
> 
> I assume JLA is no longer needed.

Right, I forgot to remove this one.

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

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

From plevart at openjdk.org  Fri Aug  5 09:54:36 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:54:36 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused JLA, SharedSecrets, added @enablePreview test annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9743/files
  - new: https://git.openjdk.org/jdk/pull/9743/files/fa2078e4..2339b87f

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

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

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

From plevart at openjdk.org  Fri Aug  5 09:54:39 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:54:39 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
Message-ID: <v3DTLd_meQGpJeXYY0wJ5-ACAamQvL4KAwpuKX0WAwE=.a16afa01-639d-4cd2-8093-04032d1ef16b@github.com>

On Thu, 4 Aug 2022 15:55:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused JLA, SharedSecrets, added @enablePreview test annotation
>
> test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40:
> 
>> 38:  * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java
>> 39:  * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal
>> 40:  */
> 
> If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. 
> 
> You might want to add the bugId to the `@bug` list too.

Done in next commit.

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

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

From jpai at openjdk.org  Fri Aug  5 09:59:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Aug 2022 09:59:52 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
Message-ID: <AXi9Hd7nQT6lsdKur_PCLSykKe0qdFO4akkVazCCWY0=.7e549036-7e5d-44e3-a979-e2afad132efa@github.com>

On Fri, 5 Aug 2022 08:59:00 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is tracked in JBS as
>> 
>> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
>> 
>> Unused imports in DTDBuider.java.
>> 
>>> **Remove unused imports from DTDBuilder.java**
>> 
>> Some imports are no more used.
>> 
>> - java.io.FileNotFoundException;
>> - java.io.BufferedInputStream;
>> - java.io.OutputStream;
>> - java.util.BitSet;
>> - java.util.StringTokenizer;
>> - java.util.Properties;
>> - java.util.zip.DeflaterOutputStream;
>> - java.util.zip.Deflater;
>> - java.net.URL;
>> 
>> https://github.com/scientificware/jdk/issues/4
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Remove unused imports.
>    
>    Some imports are no more used.
>    
>    - java.io.FileNotFoundException;
>    - java.io.BufferedInputStream;
>    - java.io.OutputStream;
>    - java.util.BitSet;
>    - java.util.StringTokenizer;
>    - java.util.Properties;
>    - java.util.zip.DeflaterOutputStream;
>    - java.util.zip.Deflater;
>    - java.net.URL;

You are right, the copyright year on the file is fine - I was looking at an older version of this file.

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

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

From lancea at openjdk.org  Fri Aug  5 10:21:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 5 Aug 2022 10:21:58 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent
 in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <MwQVKqjAOW7j_5gYKF4CLFHegExsELyG3ENFXPGhD3s=.301ca02d-fa0d-4eed-98fb-458bf53b9ba8@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

Marked as reviewed by lancea (Reviewer).

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

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

From Alan.Bateman at oracle.com  Fri Aug  5 11:21:23 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 5 Aug 2022 12:21:23 +0100
Subject: Coupling in ExtentLocal
In-Reply-To: <CAKswmE68NDCTPCY_cNnQNAwzBkXR1dM0PNfOjSk3PV0a9Poa-A@mail.gmail.com>
References: <CAKswmE58FR+GfLBEGQ6_3qhp1aFh=HqLXopTc0KFKpPwdPk30g@mail.gmail.com>
 <CAPs6153LT8WfE0xMamFuBJApJSOcGnSQnRVVE+RKnkb6eBZy=w@mail.gmail.com>
 <CAKswmE7ikJG_GA4hanweedkWYiPqTffj1tiJayp+0jBtHZWYmg@mail.gmail.com>
 <BCF4A922-6BD5-4308-B9D8-C80EA6A56040@oracle.com>
 <7da05901-89ee-0bbe-110b-c8022d4526ca@littlepinkcloud.com>
 <CAKswmE68NDCTPCY_cNnQNAwzBkXR1dM0PNfOjSk3PV0a9Poa-A@mail.gmail.com>
Message-ID: <9894e34e-5555-a78c-564e-f8af83da0b6b@oracle.com>

On 04/08/2022 20:35, Holo The Sage Wolf wrote:
> ||
>
> Some implementations of |Collection| that will always fail, some will 
> always succeed, and some implementations (like |HashSet|) may be 
> non-deterministic.
> For the uninformed this method makes sense, for each 
> |PartitiableAction| I create some kind of a new ?|Executor|? that 
> everyone is talking about, if one of the parts fails, the whole 
> calculation of this specific |PartitiableAction| will stop running, 
> and I am waiting for everything to end.
>

You may be right that someone may choose to ignore the javadoc, the 
examples, and the recommendation to use try-with-resources but that 
isn't a slam dunk argument for changing that API to use lambda 
expressions and all the usability issues that it would bring.? The 
example is a bit strange, it seems to assume that any action can process 
any input. Also the iteration order of "actions" can be deterministic 
and it will still fail because it will attempt to close the scopes in 
iteration order when it should be closing them in reverse iteration 
order. So you should see an exception at runtime if actions contains 
more than one element.

In any case, I think this is just another reminder that having language 
support that would somehow enforce the use of try-with-resources would 
be very helpful here.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220805/a5cb372e/attachment-0001.htm>

From rriggs at openjdk.org  Fri Aug  5 13:42:53 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Aug 2022 13:42:53 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent
 in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <Jrj0vYhV7sB5lO-MjaOwP0aN0Qx5bdEnCP3cgoDSoWI=.591c7fe5-b2ea-435a-888b-47f915f135df@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

Marked as reviewed by rriggs (Reviewer).

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

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

From redestad at openjdk.org  Fri Aug  5 14:39:22 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 5 Aug 2022 14:39:22 GMT
Subject: Integrated: 8288732: Reduce runtime of java.util.concurrent
 microbenchmarks
In-Reply-To: <mYymzOgt__HGcR6_bQzrxGIn6Tko1idFcukgBT3rc40=.fd7868c2-2993-44b1-8131-ca7ac5f17b79@github.com>
References: <mYymzOgt__HGcR6_bQzrxGIn6Tko1idFcukgBT3rc40=.fd7868c2-2993-44b1-8131-ca7ac5f17b79@github.com>
Message-ID: <YxlfyPCXpZL97nCOEUZ7bosGpQqhkBFnW-sZwJl-c1s=.e3fce577-7217-4271-b4c9-d284ca23bcd2@github.com>

On Mon, 20 Jun 2022 10:47:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline
> - Tune iteration times, counts, forks..
> 
> Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m

This pull request has now been integrated.

Changeset: 0da4314e
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0da4314e95f380f6125120797ad57529f5442cda
Stats:     219 lines in 12 files changed: 117 ins; 21 del; 81 mod

8288732: Reduce runtime of java.util.concurrent microbenchmarks

Reviewed-by: ecaspole, rriggs

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

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

From bpb at openjdk.org  Fri Aug  5 15:29:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 15:29:24 GMT
Subject: RFR: 8291954: Use Optional.isEmpty instead of !Optional.isPresent
 in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <Je2N6yvnpUN0iZnmbUf8ffv1b8jgel-A4lEIDZUfedI=.1d482240-cc29-4557-b7a2-c25b0a259153@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

Marked as reviewed by bpb (Reviewer).

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

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

From jlahoda at openjdk.org  Fri Aug  5 16:22:48 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Aug 2022 16:22:48 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
Message-ID: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>

The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:

switch (obj) {
    case String s when s.isEmpty() -> {}
    case String s -> {}
    case CharSequence cs -> {}
    ...
}


this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.

The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:

obj == null ? -1
                  : switch (restartIndex) {
                        case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
                        case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
                        case 2 -> obj instanceof CharSequence ? 2 : ... ;
                        ...
                        default -> <labels-count>;
                    }


This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results

PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s

PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s


The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

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

Commit messages:
 - 8291966: SwitchBootstrap.typeSwitch could be faster

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

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

From akasko at openjdk.org  Fri Aug  5 16:23:44 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Fri, 5 Aug 2022 16:23:44 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
Message-ID: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>

This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).

Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).

As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.

`getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.

Testing:

 - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
 - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

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

Commit messages:
 - 8291978: jpackage: allow to override primary l10n files on Windows

Changes: https://git.openjdk.org/jdk/pull/9780/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291978
  Stats: 105 lines in 5 files changed: 66 ins; 16 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/9780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9780/head:pull/9780

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

From naoto at openjdk.org  Fri Aug  5 16:48:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Aug 2022 16:48:10 GMT
Subject: RFR: 8291916: Unexpected output on Arabic Windows command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

Hi @takiguc,
I am not quite sure what is the rationale for moving those charsets into `java.base` module. IIUC, we typically did such a fix when the java runtime cannot boot in a supported configuration (https://bugs.openjdk.org/browse/JDK-8187910), but it seems that this issue does not warrant such a requirement. Will you elaborate more?

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

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

From akasko at openjdk.org  Fri Aug  5 17:04:54 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Fri, 5 Aug 2022 17:04:54 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

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

  reg method access, drop l10n entries, label check enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9753/files
  - new: https://git.openjdk.org/jdk/pull/9753/files/9f762674..227ad5d4

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

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

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

From akasko at openjdk.org  Fri Aug  5 17:07:24 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Fri, 5 Aug 2022 17:07:24 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <RLdv0d_hjf3H2UKlSfMglTZtuKeyNhla4JvudJbZV6I=.dda74596-8b97-493f-9fac-0f4d5a876fc1@github.com>

On Thu, 4 Aug 2022 18:10:18 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

I've updated the patch, making `queryRegistryValue` package private, removing non-EN l10n entries and adding minor enhancements to label value check.

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

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

From akasko at openjdk.org  Fri Aug  5 17:07:25 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Fri, 5 Aug 2022 17:07:25 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <ZZVXvgDBcLzp9QGdLhJPdAvGUg9Bm72Ymn6Bdb5GawE=.5c4638d5-3d3e-4d4a-9df9-383b5cfc8279@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <ZZVXvgDBcLzp9QGdLhJPdAvGUg9Bm72Ymn6Bdb5GawE=.5c4638d5-3d3e-4d4a-9df9-383b5cfc8279@github.com>
Message-ID: <YDtEIQV2FY35_urSokrrdtB909-rcoA95BFD2gMnO-k=.93dc45b9-3c53-4d49-9f67-5a5906fe5e5d@github.com>

On Thu, 4 Aug 2022 20:30:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reg method access, drop l10n entries, label check enhancement
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 359:
> 
>> 357:     }
>> 358: 
>> 359:     public static String queryRegistryValue(String keyPath, String valueName) {
> 
> It should be sufficient to make it package private, not public.

Changed the modifier to package private.

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

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

From naoto at openjdk.org  Fri Aug  5 17:14:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Aug 2022 17:14:08 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
Message-ID: <LnMVgKW_uUtyVyRwLq0dpw5N6PncktJ0msuC9nmsXIc=.1b3e7014-fba2-4026-8807-99b2e3c90cf7@github.com>

On Fri, 5 Aug 2022 17:04:54 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reg method access, drop l10n entries, label check enhancement

Looks good for the translation file change.

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

Marked as reviewed by naoto (Reviewer).

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

From svkamath at openjdk.org  Fri Aug  5 17:16:40 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 5 Aug 2022 17:16:40 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit representations
 of half precision values and floats
Message-ID: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>

8289552: Make intrinsic conversions between bit representations of half precision values and floats

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

Commit messages:
 - Intrinsic conversions between halffloat and floats

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

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

From svkamath at openjdk.org  Fri Aug  5 17:16:40 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 5 Aug 2022 17:16:40 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <fm4v2D5EiX2BKeUyc8vtWSYnCmhhLC1z7Mt1goZOnfk=.dba2284c-586b-4aa1-8ca4-c04d5c32113c@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Hi All, 
This change is to provide intrinsic implementation for conversion between floats and half precision floating point formats.
Kindly review and share your feedback.

Thanks,
Smita

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

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

From forax at univ-mlv.fr  Fri Aug  5 17:34:49 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 5 Aug 2022 19:34:49 +0200 (CEST)
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <1385192326.19042988.1659720889055.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Jan Lahoda" <jlahoda at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, August 5, 2022 6:22:48 PM
> Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster

> The pattern matching switches are using a bootstrap method
> `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically,
> for a switch like:
> 
> switch (obj) {
>    case String s when s.isEmpty() -> {}
>    case String s -> {}
>    case CharSequence cs -> {}
>    ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided
> selector value (`obj` in the example), and will return the case index to which
> the switch should jump. This method also accepts a (re)start index for the
> search, which is used to handle guards. For example, if the `s.isEmpty()` guard
> in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels
> in a loop. The proposal here is to replace that with a MethodHandle structure
> like this:
> 
> obj == null ? -1
>                  : switch (restartIndex) {
>                        case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                        case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                        case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                        ...
>                        default -> <labels-count>;
>                    }

You only need restart index at the beginning and after a when, so in your example, only 0 and 1 are required, you can skip the generation of 2 because you will never restart at 2.

If you start to see the typeswitch as a bunch of method handles, i wonder if it's not better to lift any when expressions as a static methods (exactly like a lambda body) and then send them as constant method handles to the type switch so you do not need a restart index.

Anyway, i agree that it's a better translation than the existing one.

I think that in the end game, we will go to the same route as with the lambda proxy, the whole pattern matching with the when expressions as constant method handles will be send to one bootstrap method that will create an intermediary decision tree, generate the corresponding bytecode (using the classfile API) and load it as a hidden class. This provides a clean API separation between the compiler and the runtime that knows how to optimize pattern matching query. 

R?mi

From duke at openjdk.org  Fri Aug  5 18:30:05 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 5 Aug 2022 18:30:05 GMT
Subject: RFR: JDK-8290836 Improve test coverage for XPath functions: String
 Functions [v2]
In-Reply-To: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
References: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
Message-ID: <wR1bywsMZEP6yBVWDOcB40WuqwWbw7Eogv-tH2NSq8g=.7179d88e-a211-4d8a-a160-7c8083d32c0b@github.com>

> Improve test coverage for XPath functions: [JDK-8290836](https://bugs.openjdk.org/browse/JDK-8290836), [JDK-8290837](https://bugs.openjdk.org/browse/JDK-8290837), [JDK-8290838](https://bugs.openjdk.org/browse/JDK-8290838).

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

  Added comments and fixed typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9752/files
  - new: https://git.openjdk.org/jdk/pull/9752/files/5ab30e1b..9bdb1677

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

  Stats: 137 lines in 5 files changed: 46 ins; 15 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/9752.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9752/head:pull/9752

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

From holo3146 at gmail.com  Fri Aug  5 20:22:25 2022
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Fri, 5 Aug 2022 23:22:25 +0300
Subject: Coupling in ExtentLocal
In-Reply-To: <9894e34e-5555-a78c-564e-f8af83da0b6b@oracle.com>
References: <CAKswmE58FR+GfLBEGQ6_3qhp1aFh=HqLXopTc0KFKpPwdPk30g@mail.gmail.com>
 <CAPs6153LT8WfE0xMamFuBJApJSOcGnSQnRVVE+RKnkb6eBZy=w@mail.gmail.com>
 <CAKswmE7ikJG_GA4hanweedkWYiPqTffj1tiJayp+0jBtHZWYmg@mail.gmail.com>
 <BCF4A922-6BD5-4308-B9D8-C80EA6A56040@oracle.com>
 <7da05901-89ee-0bbe-110b-c8022d4526ca@littlepinkcloud.com>
 <CAKswmE68NDCTPCY_cNnQNAwzBkXR1dM0PNfOjSk3PV0a9Poa-A@mail.gmail.com>
 <9894e34e-5555-a78c-564e-f8af83da0b6b@oracle.com>
Message-ID: <CAKswmE4L1dStGHYDEp=28MmQ3U2Jko81+FjLzjD1TFcTNV8MmA@mail.gmail.com>

slam dunk argument for changing that API to use lambda expressions

I think you misunderstood me, I am not arguing that the API should change,
I am saying that enforced try-with-resources is very relevant to almost all
?structured-API?s, and there should be work on it moving forward.

I wrote a simple error-prone plugin
<https://github.com/Holo314/forceClosable> for enforced TwR as a PoC.

On Fri, Aug 5, 2022 at 2:21 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 04/08/2022 20:35, Holo The Sage Wolf wrote:
>
> Some implementations of Collection that will always fail, some will
> always succeed, and some implementations (like HashSet) may be
> non-deterministic.
> For the uninformed this method makes sense, for each PartitiableAction I
> create some kind of a new ?Executor? that everyone is talking about, if
> one of the parts fails, the whole calculation of this specific
> PartitiableAction will stop running, and I am waiting for everything to
> end.
>
>
> You may be right that someone may choose to ignore the javadoc, the
> examples, and the recommendation to use try-with-resources but that isn't a
> slam dunk argument for changing that API to use lambda expressions and all
> the usability issues that it would bring.  The example is a bit strange, it
> seems to assume that any action can process any input. Also the iteration
> order of "actions" can be deterministic and it will still fail because it
> will attempt to close the scopes in iteration order when it should be
> closing them in reverse iteration order. So you should see an exception at
> runtime if actions contains more than one element.
>
> In any case, I think this is just another reminder that having language
> support that would somehow enforce the use of try-with-resources would be
> very helpful here.
>
> -Alan
>


-- 
Holo The Wise Wolf Of Yoitsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220805/adf1dd8a/attachment-0001.htm>

From smarks at openjdk.org  Fri Aug  5 20:43:27 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 5 Aug 2022 20:43:27 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v3]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <iyP_Gv7utuFXnz-ssE1IZPjpFuchw4JGWXL_GJV6AHw=.5fd0ead5-25c5-48ac-95a8-fb370248d5bd@github.com>

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  More updates after discussion with Alex.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/b23a7321..5a16ea30

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

  Stats: 61 lines in 2 files changed: 18 ins; 1 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

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

From smarks at openjdk.org  Fri Aug  5 20:43:27 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 5 Aug 2022 20:43:27 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v3]
In-Reply-To: <Q8As9og51DtiaPdJkX7T7uAUXVCUH5q1H4-D4WGbeo0=.eaa73407-fccb-44b9-a51f-b98a1b92cf1f@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <pQzSrmh1t4uaLnFWSiBVchn1lYP3GpPtc7vptm3WGAM=.f32fb2c4-9a9a-424f-aa1a-1949cc45b41e@github.com>
 <Tt1qKHbWsU9d34DXh3GQVrCd5Y_zUrF82LlUUcATNuY=.c5795f86-f574-4321-83fa-6e7676b46726@github.com>
 <Q8As9og51DtiaPdJkX7T7uAUXVCUH5q1H4-D4WGbeo0=.eaa73407-fccb-44b9-a51f-b98a1b92cf1f@github.com>
Message-ID: <eniw-EZvZsgmZh0ClCBVK-m7DDOT6NAGzfOHFXAmOoQ=.68dd6bd1-d5b8-4054-89ef-d6a4e4f1077c@github.com>

On Thu, 4 Aug 2022 10:00:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex and I discussed this and we felt that it was important to call out all three "kinds" of threads explicitly. Earlier versions of the text implied that no non-daemon threads were running at the time the VM terminated, which might not be true. Earlier text also implied that shutdown hooks had terminated before the VM terminated, but this isn't necessarily true if somebody calls halt(). Yes, a shutdown hook has a daemon/non-daemon bit, but effectively it's ignored, and a shutdown hook is treated so specially that it's effectively a different kind of thread.
>
> I understand but as currently worded the reader may wonder what Thread::isDaemon might return when it invoked on Thread that is a shutdown hook. I think the best I can suggest is to replace "daemon, non-daemon, and shutdown hooks" with "shutdown hooks and other daemon and non-daemon threads".

OK I used this wording.

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

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

From smarks at openjdk.org  Fri Aug  5 20:43:28 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 5 Aug 2022 20:43:28 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v2]
In-Reply-To: <dShHEBWoE4nCFIi8CgboLxQO4iqyDy68W03o4y59WKk=.37ad315b-09b5-4690-9178-c5794803e643@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <aL1GuBcZXspU6NuFBp4aJ3I7EGwJXyAQ1LHRkltS_io=.c32222e0-dc6a-4a50-a0c7-82272ee13d9a@github.com>
 <dShHEBWoE4nCFIi8CgboLxQO4iqyDy68W03o4y59WKk=.37ad315b-09b5-4690-9178-c5794803e643@github.com>
Message-ID: <TcnCUQqZC-r5AJ4vT2eONAsbT4yDWsSj-uXUBIzdv90=.14806551-716b-499f-a2a0-30a1e8eb04fd@github.com>

On Thu, 4 Aug 2022 09:52:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates after conversation with Alan:
>>   - specify that starting a shutdown hook explicitly has an unspecified
>>     effect on the shutdown sequence
>>   - link Thread class doc to shutdown sequence
>>   - link to Thread.UncaughtExceptionHandler
>>   - clarify that only live non-daemon threads are significant
>>   - use "thread termination" to conform to the text in the Thread class
>>   - adjust line breaks and whitespace
>
> src/java.base/share/classes/java/lang/Thread.java line 101:
> 
>> 99:  * the shutdown sequence from commencing. Invoking the {@linkplain Runtime#exit(int)}
>> 100:  * method will start the shutdown sequence regardless of whether non-daemon threads
>> 101:  * are still running.
> 
> Further down, in the "Virtual threads" section we have "Virtual threads are daemon threads and so do not prevent the Java virtual machine from terminating". That will need to be updated too to say that it they do not prevent the shutdown sequence from commencing.

OK I've updated this too.

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

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

From jlahoda at openjdk.org  Fri Aug  5 21:03:06 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Aug 2022 21:03:06 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <1385192326.19042988.1659720889055.JavaMail.zimbra@u-pem.fr>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <1385192326.19042988.1659720889055.JavaMail.zimbra@u-pem.fr>
Message-ID: <fXPmtVVPgwvQQShWq63_eq3-9bZNa24__bfW_Pq1Zgg=.0a1728bc-2017-4acd-b04f-14ba2f7c12bf@github.com>

On Fri, 5 Aug 2022 20:20:56 GMT, Remi Forax <forax at univ-mlv.fr> wrote:

> You only need restart index at the beginning and after a when, so in your example, only 0 and 1 are required, you can skip the generation of 2 because you will never restart at 2.
> 

The bootstrap protocol does not specify which cases have guards, so I don't think the bootstrap cannot do such a decision.

> If you start to see the typeswitch as a bunch of method handles, i wonder if it's not better to lift any when expressions as a static methods (exactly like a lambda body) and then send them as constant method handles to the type switch so you do not need a restart index.
> 

The issue with guards is that they can not only capture, but also produce new bindings. Like:

case Box b when b.o() instanceof String component -> System.err.println(component);

This really makes modeling this at runtime notably more difficult than lambdas. There were multiple experiments with this, and the runtime API and the handles are not really easy to understand.

Jan


> Anyway, i agree that it's a better translation than the existing one.
> 
> I think that in the end game, we will go to the same route as with the lambda proxy, the whole pattern matching with the when expressions as constant method handles will be send to one bootstrap method that will create an intermediary decision tree, generate the corresponding bytecode (using the classfile API) and load it as a hidden class. This provides a clean API separation between the compiler and the runtime that knows how to optimize pattern matching query.
> 
> R?mi

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

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

From kvn at openjdk.org  Fri Aug  5 22:02:11 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 5 Aug 2022 22:02:11 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <Mmwuh_Bp0Y4XNHQCPbw61P1FfGXO9KJq521h5n_4Z_Q=.253bb475-5230-4a81-95ab-edd3c5221bf6@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Please add JMH microbenchmark and show results.

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

Changes requested by kvn (Reviewer).

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

From darcy at openjdk.org  Fri Aug  5 22:19:03 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Aug 2022 22:19:03 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <FVlk5e833tCEIn7ugNEK910_C_xrbVk4pwYkC0klBY0=.77ec5cee-6ad5-4b30-b44f-9da4ceaf7081@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

src/hotspot/share/runtime/sharedRuntime.cpp line 450:

> 448: JRT_END
> 449: 
> 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat  x))

Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation?

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

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

From dholmes at openjdk.org  Fri Aug  5 22:42:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Aug 2022 22:42:21 GMT
Subject: Integrated: Merge jdk19
Message-ID: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com>

Forward port JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8290562: ThreadMXBean.getThread{Cpu,User}Time fails with -XX:-VMContinuations

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9787&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9787&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9787/files
  Stats: 99 lines in 2 files changed: 78 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/9787.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9787/head:pull/9787

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

From dholmes at openjdk.org  Fri Aug  5 22:42:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Aug 2022 22:42:22 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com>
References: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com>
Message-ID: <ia97ycDhqbfK67CREj87gKnS9nOQTMgQRjXcOUkbrok=.254a41c4-194b-480f-b5e5-958f654f5cdc@github.com>

On Fri, 5 Aug 2022 22:29:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 87cda21c
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87cda21c5d85f6e6f628849b8670e2ecb4e105dd
Stats:     99 lines in 2 files changed: 78 ins; 0 del; 21 mod

Merge

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

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

From svkamath at openjdk.org  Fri Aug  5 22:52:05 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 5 Aug 2022 22:52:05 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <Mmwuh_Bp0Y4XNHQCPbw61P1FfGXO9KJq521h5n_4Z_Q=.253bb475-5230-4a81-95ab-edd3c5221bf6@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <Mmwuh_Bp0Y4XNHQCPbw61P1FfGXO9KJq521h5n_4Z_Q=.253bb475-5230-4a81-95ab-edd3c5221bf6@github.com>
Message-ID: <qcoAqQ_L5j-n3q7EMe1q3-kSeu9l6qIaTZ7k90gPNSU=.83871b5c-1209-48d6-9f68-be7f3bfa6f2d@github.com>

On Fri, 5 Aug 2022 21:58:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Please add JMH microbenchmark and show results.

@vnkozlov Thank you for your comment. I will add a jmh test case.

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

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

From svkamath at openjdk.org  Fri Aug  5 22:54:14 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 5 Aug 2022 22:54:14 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <FVlk5e833tCEIn7ugNEK910_C_xrbVk4pwYkC0klBY0=.77ec5cee-6ad5-4b30-b44f-9da4ceaf7081@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <FVlk5e833tCEIn7ugNEK910_C_xrbVk4pwYkC0klBY0=.77ec5cee-6ad5-4b30-b44f-9da4ceaf7081@github.com>
Message-ID: <NzqmdqoUw-ofeJeiiht3Z9Qymp0Tt2fCM14FOrp_uFk=.8f9568da-c471-4668-9bd0-96bfc26454d2@github.com>

On Fri, 5 Aug 2022 22:15:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 450:
> 
>> 448: JRT_END
>> 449: 
>> 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat  x))
> 
> Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation?

@jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here.

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

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

From darcy at openjdk.org  Sat Aug  6 00:02:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 Aug 2022 00:02:06 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <NzqmdqoUw-ofeJeiiht3Z9Qymp0Tt2fCM14FOrp_uFk=.8f9568da-c471-4668-9bd0-96bfc26454d2@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <FVlk5e833tCEIn7ugNEK910_C_xrbVk4pwYkC0klBY0=.77ec5cee-6ad5-4b30-b44f-9da4ceaf7081@github.com>
 <NzqmdqoUw-ofeJeiiht3Z9Qymp0Tt2fCM14FOrp_uFk=.8f9568da-c471-4668-9bd0-96bfc26454d2@github.com>
Message-ID: <VDTS0Z_Dq3_gWsf2m8MCXNJ5P32gMrYk5NWclaJDUJM=.d8bd97e2-4071-4643-a9f3-b862fe0d3fb8@github.com>

On Fri, 5 Aug 2022 22:52:10 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 450:
>> 
>>> 448: JRT_END
>>> 449: 
>>> 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat  x))
>> 
>> Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation?
>
> @jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here.

I was under the impression that if a platform didn't have special support for the functionality in question it could not have the intrinsic and just use the Java library implementation?

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

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

From smarks at openjdk.org  Sat Aug  6 00:42:23 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 6 Aug 2022 00:42:23 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  More edits from Alex's suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/5a16ea30..d348cca4

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

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

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

From jpai at openjdk.org  Sat Aug  6 08:16:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 6 Aug 2022 08:16:47 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
Message-ID: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>

Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 

As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.

A new test has been added which reproduces the issue and verifies the fix.

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

Commit messages:
 - 8290041: ModuleDescriptor.hashCode is inconsistent

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

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

From alanb at openjdk.org  Sat Aug  6 08:27:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Aug 2022 08:27:04 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
Message-ID: <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>

On Sat, 6 Aug 2022 00:42:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Initial edits to addShutdownHook from Alex.
>> 
>> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More edits from Alex's suggestions.

src/java.base/share/classes/java/lang/System.java line 1888:

> 1886:      * Initiates the <a href="Runtime.html#shutdown">shutdown sequence</a> of the Java Virtual
> 1887:      * Machine. This method always blocks indefinitely. The
> 1888:      * argument serves as a status code; by convention, a nonzero status

Would you remind reflowing this one too as the latest change makes mixes the line lengths again.

src/java.base/share/classes/java/lang/Thread.java line 73:

> 71:  * or if its {@code run} method completes abruptly and the appropriate
> 72:  * {@linkplain Thread.UncaughtExceptionHandler uncaught exception handler} completes
> 73:  * normally or abruptly. With no code left to run, the thread has completed execution.

I'm in two minds about introducing the UHE in paragraph 3 but probably okay as you kinda have to mention it when defining termination. There's a lot more to this story when you have agents in the picture but I'll not go there. I wonder if we can do something with the last sentence that includes the word "terminated". We use "terminated" in several places and it would be cleared if this sentence were to end with something like "... the thread has completes execution, and is terminated" (it could link to isAlive or Thread.State#TERMINATED).

Given that the join method is introduced as the method to wait for a thread to terminate then it could be part of this paragraph rather than a single sentence paragraph.

src/java.base/share/classes/java/lang/Thread.java line 104:

> 102:  * The <a href="Runtime.html#shutdown">shutdown sequence</a> begins when all started
> 103:  * non-daemon threads have terminated. Unstarted non-daemon threads do not prevent
> 104:  * the shutdown sequence from commencing. Invoking the {@linkplain Runtime#exit(int)}

I think this is the only usage of "commencing", everywhere else uses "beginning" or "begin the shutdown sequence".

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

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

From duke at openjdk.org  Sat Aug  6 09:05:12 2022
From: duke at openjdk.org (Patrick Pfeifer)
Date: Sat, 6 Aug 2022 09:05:12 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
Message-ID: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>

On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>> 
>> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
>> 
>> The Java manpage was missing updates from:
>> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
>> 
>> The Java manpage has slight formatting differences from:
>> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
>> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
>> 
>> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
>> 
>> 
>> The keytool manpage was missing updates from:
>> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The jar manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jarsigner manpage was missing updates from:
>> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The javadoc manpage was missing updates from:
>> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
>> 
>> The jmod manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jpackage manpage was missing updates from:
>> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
>> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
>> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
>> 
>> The jshell manpage was missing updates from:
>> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.
>
> src/java.base/share/man/keytool.1 line 456:
> 
>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>> 455: keystore.
>> 456: This option is used to sign the certificate with the signer?s private
> 
> Not a problem with this PR as such, but we still have a `?` character in the output.

Hello @jonathan-gibbons

Excuse my hijacking / piggy-backing on this conversation!

When you say

> Not a problem with this PR as such, but we still have a `?` character in the output.

This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?

Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.

I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

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

PR: https://git.openjdk.org/jdk19/pull/145

From 1015770492 at qq.com  Sat Aug  6 09:49:18 2022
From: 1015770492 at qq.com (=?gb18030?B?KDExSTEwSTI0KSC77iC2ryDW0CDQxA==?=)
Date: Sat, 6 Aug 2022 17:49:18 +0800
Subject: More elegant multi-condition groupby. #9719
Message-ID: <tencent_B10507A99263306440A045739A77D8969309@qq.com>

Hi, team


I have two suggestions


Firstly:


If we can provide a new API for grouping (java.util.stream.Collectors&nbsp;)
such as:
userList.stream().collect(Collectors.groupingBy(User::getName, User::getCity))
userList.stream().collect(Collectors.groupingBy("-", User::getName, User::getCity, User::getId));// key is "name-city", value is&nbsp;List after being grouped


It helps us to do grouping with less code. and&nbsp;It looks cooler for lambda.


And&nbsp;I've provided a simple demo.&nbsp;
demo:&nbsp;https://github.com/1015770492/CollectorsDemo/blob/master/src/main/java/com/example/demo/MultiGroupByDemo.java
issue: https://github.com/openjdk/jdk/pull/9719


Secondly:


similarly, if we can provide new api for sort with stream.&nbsp;
It can be?
userList.stream().sorted(User::getAge)&nbsp;
or&nbsp;userList.stream().sorted(User::getName)&nbsp;&nbsp;
or&nbsp;userList.stream().sorted(User::getName, User::getAge)


userList.stream().sorted(User::getAge) age is a Integer or int type ,it is&nbsp;Comparable, So if we can use the&nbsp;Function reference&nbsp;implements sort.


String implements the&nbsp;Comparable Interface but we do not use the&nbsp;features.




userList.stream().sorted(User::getCity, User::getName)

multi-condition sort we can transfor to String sort.&nbsp;




best regards
Yu, Jinhua
1015770492 at qq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220806/d07d282f/attachment.htm>

From aturbanov at openjdk.org  Sat Aug  6 09:56:40 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 6 Aug 2022 09:56:40 GMT
Subject: Integrated: 8291954: Use Optional.isEmpty instead of
 !Optional.isPresent in java.base
In-Reply-To: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
References: <nswDy0DfsIlla5z0JiywrRjUuBZzpxM0I5xojJRuccY=.3517ab79-7932-4184-9816-821227042458@github.com>
Message-ID: <AdYfs6_-75u72V4CCj_28Gewe6wSINMEVKeyDo8fubA=.2c64596c-510f-439d-9012-2dd3846a9d79@github.com>

On Mon, 1 Aug 2022 06:51:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method.
> It's makes code a bit easier to read.
> Noticing negation before long chain of method calls is hard.

This pull request has now been integrated.

Changeset: ae520537
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae52053757ca50c4b56989c9b0c6890e504e4088
Stats:     23 lines in 6 files changed: 0 ins; 2 del; 21 mod

8291954: Use Optional.isEmpty instead of !Optional.isPresent in java.base

Reviewed-by: jpai, alanb, lancea, rriggs, bpb

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

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

From jwaters at openjdk.org  Sat Aug  6 10:18:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 6 Aug 2022 10:18:08 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
Message-ID: <WD1KJjRhZtnVu7nuxJHF7gQmoKO2IAv66BLBSLiqrAk=.fdc62f81-d3e5-4587-836d-518bc973fa77@github.com>

On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing spacing between errors

Not entirely sure if that's the intended use of JLI_ReportErrorMessageSys, but since Windows doesn't actually use it normally, the fixing change to it should have minimal impact, if at all

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

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

From stuefe at openjdk.org  Sat Aug  6 10:57:59 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 6 Aug 2022 10:57:59 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
Message-ID: <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>

On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing spacing between errors

Hi Julian,

I don't get it.

AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent).

I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function.

Cheers, Thomas

src/java.base/share/native/libjli/emessages.h line 111:

> 109: #define DLL_ERROR2      "Error: failed %s, because %s"
> 110: #define DLL_ERROR3      "Error: could not find executable %s"
> 111: #define DLL_ERROR4      "Error: Failed to load %s"

Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases.

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

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

From jwaters at openjdk.org  Sat Aug  6 11:21:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 6 Aug 2022 11:21:03 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
 <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
Message-ID: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com>

On Sat, 6 Aug 2022 10:36:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing spacing between errors
>
> src/java.base/share/native/libjli/emessages.h line 111:
> 
>> 109: #define DLL_ERROR2      "Error: failed %s, because %s"
>> 110: #define DLL_ERROR3      "Error: could not find executable %s"
>> 111: #define DLL_ERROR4      "Error: Failed to load %s"
> 
> Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases.

The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path:

static JLI_List expandArgFile(const char *arg) {
    JLI_List rv;
    struct stat st;
    FILE *fptr = fopen(arg, "r");

    /* arg file cannot be opened */
    if (fptr == NULL || fstat(fileno(fptr), &st) != 0) {
        JLI_ReportMessage(CFG_ERROR6, arg);
        exit(1);
    } else {
        if (st.st_size > MAX_ARGF_SIZE) {
            JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
            exit(1);
        }
    }

    rv = readArgFile(fptr);

    /* error occurred reading the file */
    if (rv == NULL) {
        JLI_ReportMessage(DLL_ERROR4, arg);
        exit(1);
    }
    fclose(fptr);

    return rv;
}


In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used

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

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

From stuefe at openjdk.org  Sat Aug  6 11:40:06 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 6 Aug 2022 11:40:06 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
 <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
 <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com>
Message-ID: <kjh0wTPSilMFNvUdz-I2BJtowW34SOFlAOjzxvVzTIQ=.da630f52-c149-46d0-9b9a-0c2f9197aab0@github.com>

On Sat, 6 Aug 2022 11:14:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.base/share/native/libjli/emessages.h line 111:
>> 
>>> 109: #define DLL_ERROR2      "Error: failed %s, because %s"
>>> 110: #define DLL_ERROR3      "Error: could not find executable %s"
>>> 111: #define DLL_ERROR4      "Error: Failed to load %s"
>> 
>> Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases.
>
> The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path:
> 
> static JLI_List expandArgFile(const char *arg) {
>     JLI_List rv;
>     struct stat st;
>     FILE *fptr = fopen(arg, "r");
> 
>     /* arg file cannot be opened */
>     if (fptr == NULL || fstat(fileno(fptr), &st) != 0) {
>         JLI_ReportMessage(CFG_ERROR6, arg);
>         exit(1);
>     } else {
>         if (st.st_size > MAX_ARGF_SIZE) {
>             JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
>             exit(1);
>         }
>     }
> 
>     rv = readArgFile(fptr);
> 
>     /* error occurred reading the file */
>     if (rv == NULL) {
>         JLI_ReportMessage(DLL_ERROR4, arg);
>         exit(1);
>     }
>     fclose(fptr);
> 
>     return rv;
> }
> 
> 
> In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used

You also have one use where the VM does a GetProcAddress on windows. "Failed to load" feels wrong for a failed dlsym. But "Error loading" is not much better either, I admit.

In general, the smaller and focused you keep changes, the easier they are to review and the better they are down-portable if that should be needed. I usually try to do aesthetic changes in separate RFEs. In this change, if you want to fix the display of additional diagnostic info, I'd just do that.

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

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

From jwaters at openjdk.org  Sat Aug  6 12:23:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 6 Aug 2022 12:23:07 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
 <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
Message-ID: <SIWVRL8nWkJR9J-Dsxsbg6BuUKve1dqPrvypHhueVTQ=.0c6330ed-b202-4ff4-b83b-b03264fa957e@github.com>

On Sat, 6 Aug 2022 10:54:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Julian,
> 
> I don't get it.
> 
> AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent).
> 
> I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function.
> 
> Cheers, Thomas

Hi Thomas, sorry for the delay,

Yes, the bug was the CRT errors being omitted, the issue with setting freeit for CRT errors too is that it, from what I can see, is only supposed to be used by the branch for Win32 errors, and is used for calling LocalFree (required for FormatMessage) later on. Setting this for CRT errors would mean LocalFree is passed something that LocalAlloc did not allocate, which would likely result in bad things happening. I didn't feel like changing too much of the existing logic just to fix a small issue and decided to leave the calculation and concatenation of the message to other JLI functions, but that may have been a misjudgement on my part.

JLI_ReportErrorMessageSys is documented to deliberately leave the formatting of spacing up to the caller - Which is why no changes were made to it to accomodate that quirk. Admittedly a strcat could've been used in the caller rather than an additional format specifer though, like you mentioned

best regards,
Julian

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

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

From jwaters at openjdk.org  Sat Aug  6 12:23:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 6 Aug 2022 12:23:08 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <kjh0wTPSilMFNvUdz-I2BJtowW34SOFlAOjzxvVzTIQ=.da630f52-c149-46d0-9b9a-0c2f9197aab0@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
 <eXiufRGmKlKOpZeFUM8eyR_sOzrKNgiJn9HKTjUGpsk=.c6827d09-d5c8-4b92-bcac-0b76f97feec2@github.com>
 <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com>
 <kjh0wTPSilMFNvUdz-I2BJtowW34SOFlAOjzxvVzTIQ=.da630f52-c149-46d0-9b9a-0c2f9197aab0@github.com>
Message-ID: <8r07t1mVOVOCYQCHcDubl1_ZxPyJvOsEj0_V6EIwUAA=.4d2573fe-c025-4a9a-8a76-ac6b1b7241a1@github.com>

On Sat, 6 Aug 2022 11:36:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path:
>> 
>> static JLI_List expandArgFile(const char *arg) {
>>     JLI_List rv;
>>     struct stat st;
>>     FILE *fptr = fopen(arg, "r");
>> 
>>     /* arg file cannot be opened */
>>     if (fptr == NULL || fstat(fileno(fptr), &st) != 0) {
>>         JLI_ReportMessage(CFG_ERROR6, arg);
>>         exit(1);
>>     } else {
>>         if (st.st_size > MAX_ARGF_SIZE) {
>>             JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
>>             exit(1);
>>         }
>>     }
>> 
>>     rv = readArgFile(fptr);
>> 
>>     /* error occurred reading the file */
>>     if (rv == NULL) {
>>         JLI_ReportMessage(DLL_ERROR4, arg);
>>         exit(1);
>>     }
>>     fclose(fptr);
>> 
>>     return rv;
>> }
>> 
>> 
>> In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used
>
> You also have one use where the VM does a GetProcAddress on windows. "Failed to load" feels wrong for a failed dlsym. But "Error loading" is not much better either, I admit.
> 
> In general, the smaller and focused you keep changes, the easier they are to review and the better they are down-portable if that should be needed. I usually try to do aesthetic changes in separate RFEs. In this change, if you want to fix the display of additional diagnostic info, I'd just do that.

Agreed, will split this part into another RFE (initially didn't do this because such a change felt too trivial for an entire entry in the JBS), but I do feel like waiting for more opinions on what the prefix should be changed to before doing that

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

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

From asemenyuk at openjdk.org  Sat Aug  6 12:29:51 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 6 Aug 2022 12:29:51 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <3odxre-1E5qs1APtmY4-XRemoUNSv1we4Xm04A2DQFw=.955d4981-4150-4c16-b5dc-13dd3c7e1388@github.com>

On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

Marked as reviewed by asemenyuk (Reviewer).

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

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

From asemenyuk at openjdk.org  Sat Aug  6 12:46:01 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 6 Aug 2022 12:46:01 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
Message-ID: <jB-kUhX7tC17YfrDVyN5TDWooJxCYv7CnoxhG6WNebE=.196664fd-cc35-4fef-8658-8a246ddde26f@github.com>

On Fri, 5 Aug 2022 17:04:54 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reg method access, drop l10n entries, label check enhancement

I think there was a miscommunication about l10n files.
All "MsiInstallerStrings_*.wxl" files need to be updated, but no need to provide a localized version of English string(s). 
I.e. add `<String Id="ContextMenuCommandLabel">Open with [ProductName]</String>` to all "MsiInstallerStrings_*.wxl" files, not only to "MsiInstallerStrings_en.wxl".

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

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

From stuefe at openjdk.org  Sat Aug  6 13:08:56 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 6 Aug 2022 13:08:56 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v3]
In-Reply-To: <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <HFycGNm_jjT5EVrb7QXnbwWYDU1ir25vVF_ZPngGMuQ=.46fcf367-80eb-4f20-8d45-7543473c36c7@github.com>
Message-ID: <ySRS5nf1a8EcTfK1mNBINgVqywn0g1V2KlF9i_pnNMM=.a4c8196f-22d4-4cf5-b9a5-54a6ff4b7a20@github.com>

On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing spacing between errors

Hi Julian,

> > Hi Julian,
> > I don't get it.
> > AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent).
> > I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function.
> > Cheers, Thomas
> 
> Hi Thomas, sorry for the delay,
> 

why, there was no delay :-)

> Yes, the bug was the CRT errors being omitted, the issue with setting freeit for CRT errors too is that it, from what I can see, is only supposed to be used by the branch for Win32 errors, and is used for calling LocalFree (required for FormatMessage) later on. Setting this for CRT errors would mean LocalFree is passed something that LocalAlloc did not allocate, which would likely result in bad things happening. 

Oh right. I see. Not your change, but I am not a big fan of this pattern (mixing CRT and win32 error handling). This is broken since it assumes that win32 error code and errno are mutually exclusive, or somehow related, which they are not. A lingering GetLastError() from some earlier win32 API call could be misreported as error detail for a follow-up CRT error. The correct way to do this would be to have two functions, one for failing win32 APIs, one for failing CRT functions. And let the caller decide what to call.

> I didn't feel like changing too much of the existing logic just to fix a small issue and decided to leave the calculation and concatenation of the message to other JLI functions, but that may have been a misjudgement on my part.

If you can make the fix for the CRT extra info small, I'd go for it.

> 
> JLI_ReportErrorMessageSys is documented to deliberately leave the formatting of spacing up to the caller - Which is why no changes were made to it to accomodate that quirk. Admittedly a strcat could've been used in the caller rather than an additional format specifer though, like you mentioned

I think it would be reasonable to expect that the additional info printed by that function gets visually separated somehow from the error text the caller hands in.

Note, btw, if you change output like this, make sure to check all test sources for tests that may grep the output. Not sure how likely this is here. Just something to keep in mind. This is nothing an IDE will tell you, unfortunately.

Cheers, Thomas

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

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

From naoto at openjdk.org  Sat Aug  6 13:52:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 6 Aug 2022 13:52:06 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
Message-ID: <vVEHVguD1D_BW1FTuznHEU-P0P1TDTV-7-8LsOHfh6U=.441bd18a-6168-4a43-86a2-526e6e50a3be@github.com>

On Fri, 5 Aug 2022 17:04:54 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reg method access, drop l10n entries, label check enhancement

Missing entries in localized files are automatically detected by the translation process. So modifying only the English file should be fine.

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

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

From duke at openjdk.org  Sat Aug  6 13:54:20 2022
From: duke at openjdk.org (Patrick Pfeifer)
Date: Sat, 6 Aug 2022 13:54:20 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com>

On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer <duke at openjdk.org> wrote:

>> src/java.base/share/man/keytool.1 line 456:
>> 
>>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>>> 455: keystore.
>>> 456: This option is used to sign the certificate with the signer?s private
>> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
>
> Hello @jonathan-gibbons
> 
> Excuse my hijacking / piggy-backing on this conversation!
> 
> When you say
> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?
> 
> Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.
> 
> I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

It did not take much effort to answer the last of the above question myself.

> Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

Obviously "yes". HTML renderings can be found by following the, e.g. "[Java Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/index.html)" Link on the "Specifications Overview" page at, e.g. "https://docs.oracle.com/en/java/javase/18/docs/specs/".

Still hunting for the sources.

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

PR: https://git.openjdk.org/jdk19/pull/145

From duke at openjdk.org  Sat Aug  6 14:55:17 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 6 Aug 2022 14:55:17 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

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

 - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
 - Mark StackTraceElement SerialTest for bug 8291641
 - Revert "Mark StackTraceElement SerialTest for bug 8291641"
   
   This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
 - Mark StackTraceElement SerialTest for bug 8291641
 - Inline max Integer.stringSize
 - Estimate length
 - Address comments
 - Precompute StackTraceElement toString length
 - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
 - Optimize StackTraceElement.toString()
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ba1acce5...c9ae3897

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/c93ac5af..c9ae3897

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

  Stats: 7078 lines in 345 files changed: 4410 ins; 1722 del; 946 mod
  Patch: https://git.openjdk.org/jdk/pull/9665.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9665/head:pull/9665

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

From openjdk at icemanx.nl  Sat Aug  6 16:12:19 2022
From: openjdk at icemanx.nl (Rob Spoor)
Date: Sat, 6 Aug 2022 18:12:19 +0200
Subject: [BUG]
 Collections.unmodifiableMap(map).entrySet().iterator().forEachRemaining is
 missing null check
Message-ID: <8221372d-d6d6-28e4-4ef3-22321fdb7f56@icemanx.nl>

Hi,

I was working on upgrading another library of mine from Java 8 to 11, 
and I noticed my unit tests started failing. Some debugging traced the 
cause back to java.util.Collections$UnmodifiableMap$UnmodifiableEntrySet 
and its iterator() implementation.

In Java 8, the implementation only implemented hasNext, next and remove. 
It inherited forEachRemaining from java.util.Iterator, which first does 
a null check.

Since Java 11, the forEachRemaining is overridden:

public void forEachRemaining(Consumer<? super Map.Entry<K, V>> action) {
     i.forEachRemaining(entryConsumer(action));
}

The thing is, entryConsumer does not perform any null checks. That's 
done before entryConsumer is called in all occurrences but this one. The 
result is that a non-null action is passed to i.forEachRemaining, which 
causes the iterator to move forward before a NullPointerException is 
thrown. The solution is of course simple: add 
Objects.requireNonNull(action); to the method.

Rob

From jwaters at openjdk.org  Sat Aug  6 16:45:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 6 Aug 2022 16:45:06 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Back out change to DLL_ERROR4 for separate RFE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/3bd53488..990ee4fd

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

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

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

From jwaters at openjdk.org  Sun Aug  7 06:14:48 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 7 Aug 2022 06:14:48 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
Message-ID: <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>

On Sat, 6 Aug 2022 16:45:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back out change to DLL_ERROR4 for separate RFE

Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P

I am slightly concerned with going the route of 2 different calls for WIN32 and the C runtime, since `JLI_ReportErrorMessageSys` is a shared function, only the implementations differ from platform to platform. I can't think of any solution off the top of my head to implement such a change without drastically changing either the Unix variant as well, or the declaration's signature in the shared header unfortunately.

I was initially hesitant to change the formatting of spacing between the caller's message and system error, since the original intention for leaving it up to the caller may have been to allow for better flexibility. Also a concern was any behaviour differences that might result with the Unix variant, but it seems like the 2 format their messages entirely differently - While Windows appends the system error to the message without any formatting, Unix prints the system error on an entirely separate line above the message the caller passed it:

JNIEXPORT void JNICALL
JLI_ReportErrorMessageSys(const char* fmt, ...) {
    va_list vl;
    char *emsg;

    /*
     * TODO: its safer to use strerror_r but is not available on
     * Solaris 8. Until then....
     */
    emsg = strerror(errno);
    if (emsg != NULL) {
        fprintf(stderr, "%s\n", emsg);
    }

    va_start(vl, fmt);
    vfprintf(stderr, fmt, vl);
    fprintf(stderr, "\n");
    va_end(vl);
}


> If you can make the fix for the CRT extra info small, I'd go for it.

I don't quite get what you mean by that, should I revert the changes made to the freeit checks?

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

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

From stuefe at openjdk.org  Sun Aug  7 07:50:49 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 7 Aug 2022 07:50:49 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
 <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
Message-ID: <Fm0HUsbv363bM8cFr3tYPGbXqTl-o0yg64-jVCI2HpQ=.345fceb7-3ab4-4ff3-ab5c-2839d96c16b5@github.com>

On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I don't quite get what you mean by that, should I revert the changes made to the freeit checks?

I looked over this function and found a number of issues with it. I created https://bugs.openjdk.org/browse/JDK-8292016 to track those (if you feel like it, feel free to take it over).

I think now that this PR fixes an isolated problem, but it would be better and less review work to rework this function as https://bugs.openjdk.org/browse/JDK-8292016 suggests.

I also believe that your bug description in the JBS does not correctly describe the Bug. See my comment in JBS. If you open bugs like this, it is always helpful to be precise, and possibly append failing output (e.g. in this case the output of DLL load errors).

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

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

From plevart at openjdk.org  Sun Aug  7 08:00:05 2022
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 7 Aug 2022 08:00:05 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <Bghwv9PezXdZQJu-G5eTJ1gxdERwLxDliNUZh3Z2rs0=.69a99801-ffd7-41d4-aeb6-1439a6f9ee81@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2630:

> 2628:         int h = 0;
> 2629:         for (Enum<?> e : enums) {
> 2630:             h = h + Objects.hashCode(e.name()) * 43;

why * 43 ? Isn't String.hashCode good enough?

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

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

From alanb at openjdk.org  Sun Aug  7 08:00:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 7 Aug 2022 08:00:42 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <Fm0HUsbv363bM8cFr3tYPGbXqTl-o0yg64-jVCI2HpQ=.345fceb7-3ab4-4ff3-ab5c-2839d96c16b5@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
 <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
 <Fm0HUsbv363bM8cFr3tYPGbXqTl-o0yg64-jVCI2HpQ=.345fceb7-3ab4-4ff3-ab5c-2839d96c16b5@github.com>
Message-ID: <rOOTWYYjyoVfuSQXuigKKB4X2rn2HZGapW72V5K_gKk=.cf6ff7cb-e31b-48cb-a30d-f78ec77ad6d4@github.com>

On Sun, 7 Aug 2022 07:47:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> If you open bugs like this, it is always helpful to be precise, and possibly append failing output (e.g. in this case the output of DLL load errors).

I agree, I think it would be useful to provide a summary where the launcher fails and the before/after output so that it's clear what we are looking at.

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

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

From stuefe at openjdk.org  Sun Aug  7 08:00:43 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 7 Aug 2022 08:00:43 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
 <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
Message-ID: <0uuBnaZ4vxnwvwqPZzTniup_5ZxVSs_iq47NGmUzLFg=.09f9ee79-d50a-40ab-87aa-37a1a36e7699@github.com>

On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P

Oh, that is fine :) Thanks for looking. I just mentioned it since you are new-ish. The tests that run as part of GHAs are only a tiny subset of all tests though, therefore there can be tests that fail and you would not notice.

About the rest, starting to pull a thread somewhere and then noticing that the thread gets longer and longer is a normal thing. Then its up to you to decide whether fixing the isolated issue is worth it or whether more code needs to be reworked.

Cheers, Thomas

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

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

From plevart at openjdk.org  Sun Aug  7 08:04:07 2022
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 7 Aug 2022 08:04:07 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <MkJ32ZzRF4i94zHmf0Xa-j17qWucidy-gUV8GuDUcJM=.1010bf33-974c-484b-b704-1e160e7fbf6f@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

Hi,
Sorry for joining late. I noticed that modsHashCode is a private method and it takes Iterable<? extends Enum<?>> as a parameter. But everywhere it is called, a Set<? extends Enum<?>> is passed to it. So why not just calling the set.hashCode() and be done with it? It may be even more optimal in some cases.

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

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

From alanb at openjdk.org  Sun Aug  7 08:19:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 7 Aug 2022 08:19:03 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <v_OWfLAWNiNej5iXxbd6EAipBgBX21Zx8XyiWu7HEas=.6c5119a3-ac72-4ae7-b96a-503715e3b842@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

> Sorry for joining late. I noticed that modsHashCode is a private method and it takes Iterable> as a parameter. But everywhere it is called, a Set> is passed to it. So why not just calling the set.hashCode() and be done with it? It may be even more optimal in some cases.

There's a lot going on here as the hash code is generated at link time and we also want it to be reproducible across builds. We also had a CDS bug with the  the way that Enum objects were archived - Ioi has fixed that in JDK 19 so we have one less thing to be concerned about now.

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

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

From jwaters at openjdk.org  Sun Aug  7 08:39:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 7 Aug 2022 08:39:42 GMT
Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime
 libraries fail to load [v4]
In-Reply-To: <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
Message-ID: <mnfRw-2TzgAusgwHxiMoHN4xEpWRSwLN0iBFyAUg5jQ=.05cef744-313d-4a21-a9a4-748a021e3b61@github.com>

On Sat, 6 Aug 2022 16:45:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back out change to DLL_ERROR4 for separate RFE

Yeah, does seem like this PR is going to have to wait until [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) is resolved

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

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

From david.holmes at oracle.com  Sun Aug  7 23:59:08 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 8 Aug 2022 09:59:08 +1000
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
Message-ID: <161d24ca-ff52-b2fe-0874-461e98900e28@oracle.com>

Hi Patrick,

On 6/08/2022 7:05 pm, Patrick Pfeifer wrote:
> On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
> 
>>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>>
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> Hello @jonathan-gibbons
> 
> Excuse my hijacking / piggy-backing on this conversation!
> 
> When you say
> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
> 
> This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo?

The sources to the manpages are not currently open sourced and so are 
held in Oracle's internal repository. Making them open-sourced has been 
a goal for some time now but has to overcome legal obstacles, but we are 
hopeful it will be "soon".

> Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build.
> 
> I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web?

As you found, Oracle does provide these in html format.

Cheers,
David


> -------------
> 
> PR: https://git.openjdk.org/jdk19/pull/145

From itakiguchi at openjdk.org  Mon Aug  8 00:24:04 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 8 Aug 2022 00:24:04 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
Message-ID: <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>

On Thu, 7 Jul 2022 09:47:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And also there is no reason why db drivers or host connectors should not ship their own charset support \(Oracle JDBC for example had nls\_charset addons\. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks\, and that took some effort to adopt it to the missing ext mechanism\)\.
>> 
>> Having said that\, with JPMS a \?legacy ebcdic\? encoding module would be possible while still being optional\. Maybe in the future a mechanism for modules which can be added \(instead of removed\) from standard distribution would make that nicer\?
>> 
>> Is there a performance restriction for charset if they are not part of a platform module \(optimized string access\)\?
>> 
>> Gruss
>> Bernd
>> 
>> 
>> \-\-
>> http\:\/\/bernd\.eckenfels\.net
>> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>> Von\: core\-libs\-dev \<core\-libs\-dev\-retn at openjdk\.org> im Auftrag von Alan Bateman \<alanb at openjdk\.org>
>> Gesendet\: Thursday\, July 7\, 2022 11\:50\:39 AM
>> An\: build\-dev at openjdk\.org \<build\-dev at openjdk\.org>\; core\-libs\-dev at openjdk\.org \<core\-libs\-dev at openjdk\.org>\; i18n\-dev at openjdk\.org \<i18n\-dev at openjdk\.org>
>> Betreff\: Re\: RFR\: 8289834\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> On Wed\, 6 Jul 2022 16\:18\:08 GMT\, Ichiroh Takiguchi \<itakiguchi at openjdk\.org> wrote\:
>> 
>>> Discussions are available on \:
>>> \[JDK\-8289834\]\(https\:\/\/bugs\.openjdk\.org\/browse\/JDK\-8289834\)\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> Yes\, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets\. I understand they can be useful for someone using JDBC to connect to a database on z\/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path\. Do you know if the icu4j project is still alive\? I\'ve often wondered why there wasn\'t more use of the provider mechanism\.
>> 
>> \-\-\-\-\-\-\-\-\-\-\-\-\-
>> 
>> PR\: https\:\/\/git\.openjdk\.org\/jdk\/pull\/9399
>> \-\-\-\-\-\-\-\-\-\-\-\-\-\- next part \-\-\-\-\-\-\-\-\-\-\-\-\-\-
>> An HTML attachment was scrubbed\.\.\.
>> URL\: \<https\:\/\/mail\.openjdk\.org\/pipermail\/core\-libs\-dev\/attachments\/20220707\/2d095f3d\/attachment\-0001\.htm>
>
>> Discussions are available on :
>> [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets
> 
> Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism.

Hello @AlanBateman .
Sorry I'm late.
I got some responses from ICU. [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
I'm not sure if they're interested in the new charset...

As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage.
And some other performance advantages are there on built-in charset decoder/encoder.
Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes?
We'd like to use stable conversion loop.

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

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

From itakiguchi at openjdk.org  Mon Aug  8 01:37:38 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 8 Aug 2022 01:37:38 GMT
Subject: RFR: 8291916: Unexpected output on Arabic Windows command prompt
In-Reply-To: <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
 <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>
Message-ID: <zXwZ1vYsjQbsTBRUeR0tC5eKb1xaHY0Uh66TeUcW6nE=.ddf86f0f-58c8-4d19-84fa-71ba042a55c7@github.com>

On Fri, 5 Aug 2022 16:44:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
>> 
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> Hi @takiguc,
> I am not quite sure what is the rationale for moving those charsets into `java.base` module. IIUC, we typically did such a fix when the java runtime cannot boot in a supported configuration (https://bugs.openjdk.org/browse/JDK-8187910), but it seems that this issue does not warrant such a requirement. Will you elaborate more?

Hello @naotoj .
As Alan was described, windows codepage mapping table is as follows

- 860 - Portuguese (DOS) - IBM860
- 861 - Icelandic (DOS) - IBM861
- 863 - French Canadian (DOS) - IBM863
- 864 - Arabic (864) - IBM864
- 865 - Nordic (DOS) - IBM865
- 869 - Greek, Modern (DOS) - IBM869

Java 8 implementation is as follows:
Windows command prompt setting, following sample is 864.

>chcp 864
Active code page: 864

Test program

>type termdump.java
import java.nio.charset.*;

public class termdump {
  public static void main(String[] args) throws Exception {
    String csname = System.getProperty("sun.stdout.encoding");
    if (csname == null) csname = System.getProperty("stdout.encoding");
    System.out.println(csname);
    Charset cs = Charset.forName(csname);
    for (int i0 = 0; i0 < 0x100; i0 += 0x10) {
      StringBuilder sb = new StringBuilder();
      for (int i1 = 0; i1 < 0x10; i1++) {
        byte[] ba = new byte[1];
        ba[0] = (byte) (i0 | i1);
        String s = new String(ba, csname);
        if (s.length() == 1) {
          char ch = s.charAt(0);
          if (ch < 0x7F) continue;
          if (Character.isISOControl(ch)) continue;
          if (ch == '\uFFFD') continue;
          sb.append(ch);
        }
      }
      if (sb.length() > 0) {
        System.out.printf("0x%02X %s%n", i0, sb.toString());
        System.out.print("    ");
        for (char ch : sb.toString().toCharArray()) {
          System.out.printf(" %04X", (int)ch);
        }
        System.out.println();
      }
    }
  }
}

Java8 output

>jdk8u345-b01\jre\bin\java termdump
cp864
0x20 %
     066A
0x80 ????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ?????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ??????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ???????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

Java20 output

>jdk-20\bin\java termdump
cp864
0x20 ??
     066A
0x80 ??????????????????????????????????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ????????????????????????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ?????????????????????????????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????????????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ???????????????????????????????????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????????????????????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ???????????????????????????????????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ????????????????????????????????????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

Fixed output

>java -showversion termdump
openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.Administrator.jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.Administrator.jdk, mixed mode, sharing)
cp864
0x20 %
     066A
0x80 ????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ?????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ??????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ???????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

863's output is as follows:

>chcp 863
Active code page: 863

>jdk8u345-b01\jre\bin\java termdump
cp863
0x80 ????????????????
     00C7 00FC 00E9 00E2 00C2 00E0 00B6 00E7 00EA 00EB 00E8 00EF 00EE 2017 00C0 00A7
0x90 ????????????????
     00C9 00C8 00CA 00F4 00CB 00CF 00FB 00F9 00A4 00D4 00DC 00A2 00A3 00D9 00DB 0192
0xA0 ????????????????
     00A6 00B4 00F3 00FA 00A8 00B8 00B3 00AF 00CE 2310 00AC 00BD 00BC 00BE 00AB 00BB
0xB0 ????????????????
     2591 2592 2593 2502 2524 2561 2562 2556 2555 2563 2551 2557 255D 255C 255B 2510
0xC0 ????????????????
     2514 2534 252C 251C 2500 253C 255E 255F 255A 2554 2569 2566 2560 2550 256C 2567
0xD0 ????????????????
     2568 2564 2565 2559 2558 2552 2553 256B 256A 2518 250C 2588 2584 258C 2590 2580
0xE0 ????????????????
     03B1 00DF 0393 03C0 03A3 03C3 00B5 03C4 03A6 0398 03A9 03B4 221E 03C6 03B5 2229
0xF0 ????????????????
     2261 00B1 2265 2264 2320 2321 00F7 2248 00B0 2219 00B7 221A 207F 00B2 25A0 00A0

>jdk-20\bin\java termdump
cp863
0x80 ?????????????????????????????????
     00C7 00FC 00E9 00E2 00C2 00E0 00B6 00E7 00EA 00EB 00E8 00EF 00EE 2017 00C0 00A7
0x90 ????????????????????????????????
     00C9 00C8 00CA 00F4 00CB 00CF 00FB 00F9 00A4 00D4 00DC 00A2 00A3 00D9 00DB 0192
0xA0 ?????????????????????????????????
     00A6 00B4 00F3 00FA 00A8 00B8 00B3 00AF 00CE 2310 00AC 00BD 00BC 00BE 00AB 00BB
0xB0 ????????????????????????????????????????????????
     2591 2592 2593 2502 2524 2561 2562 2556 2555 2563 2551 2557 255D 255C 255B 2510
0xC0 ????????????????????????????????????????????????
     2514 2534 252C 251C 2500 253C 255E 255F 255A 2554 2569 2566 2560 2550 256C 2567
0xD0 ????????????????????????????????????????????????
     2568 2564 2565 2559 2558 2552 2553 256B 256A 2518 250C 2588 2584 258C 2590 2580
0xE0 ??????????????????????????????????
     03B1 00DF 0393 03C0 03A3 03C3 00B5 03C4 03A6 0398 03A9 03B4 221E 03C6 03B5 2229
0xF0 ??????????????????????????????????????????
     2261 00B1 2265 2264 2320 2321 00F7 2248 00B0 2219 00B7 221A 207F 00B2 25A0 00A0

We are in final phase to migrate from Java8 to next stable Java.
I think tt should be fixed.

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

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

From dholmes at openjdk.org  Mon Aug  8 02:42:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Aug 2022 02:42:06 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
Message-ID: <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>

On Sat, 6 Aug 2022 00:42:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Initial edits to addShutdownHook from Alex.
>> 
>> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More edits from Alex's suggestions.

Hi Stuart,

Looking good overall. A few minor comments and one more substantive one regarding `DestroyJavaVM`.

Thanks,
David

src/java.base/share/classes/java/lang/Runtime.java line 55:

> 53:  * to one of several events:
> 54:  * <ol>
> 55:  * <li>when the number of {@linkplain Thread#isAlive() live} non-daemon threads drops to zero

Can we somehow forward-reference the implNote about DestroyJavaVM here?

src/java.base/share/classes/java/lang/Runtime.java line 66:

> 64:  * {@linkplain Thread#start started} in some unspecified order. They run concurrently
> 65:  * with any daemon or non-daemon threads that were {@linkplain Thread#isAlive() alive}
> 66:  * at the beginning of the shutdown sequence.

or which subsequently get started as covered later. So perhaps a simple reordering here:

> <p>At the beginning of the shutdown sequence, the registered shutdown hooks are  {@linkplain Thread#start started} in some unspecified order.

> <p>After the shutdown sequence has begun, registration and de-registration of shutdown hooks with {@link #addShutdownHook addShutdownHook} and {@link #removeShutdownHook removeShutdownHook} is prohibited. However, creating and starting new threads is permitted.

> <p> The shutdown hooks run concurrently with any daemon or non-daemon threads that were {@linkplain Thread#isAlive() alive} at the beginning of the shutdown sequence; or which are subsequently started.

src/java.base/share/classes/java/lang/Runtime.java line 85:

> 83:  * effect on the shutdown sequence is unspecified.
> 84:  *
> 85:  * <h2><a id="termination">Virtual Machine Termination</a></h2>

Should this say "Java Virtual Machine Termination" for consistency.

src/java.base/share/classes/java/lang/Runtime.java line 99:

> 97:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">DestroyJavaVM</a>.
> 98:  * This function is responsible for initiating the shutdown sequence when the number of running
> 99:  * ({@linkplain Thread#isAlive() live}) non-daemon threads first drops to zero. When the shutdown

I think we need to align this more with the proposed text of JLS 12.8. It needs to be clearer that `DestroyJavaVM` must be used in conjunction with `CreateJavaVM` to get the desired termination behaviour. Otherwise, the proposed text allows for the possibility that the JVM will always terminate when the last non-daemon thread terminates, even if `DestroyJavaVM` has not been called. It needs to be clear that if the JVM is started by the JNI Invocation API, then it must also be terminated by the JNI invocationAPI to get the required behaviour.

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

Changes requested by dholmes (Reviewer).

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

From dholmes at openjdk.org  Mon Aug  8 02:42:09 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Aug 2022 02:42:09 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
Message-ID: <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>

On Sat, 6 Aug 2022 08:11:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More edits from Alex's suggestions.
>
> src/java.base/share/classes/java/lang/Thread.java line 73:
> 
>> 71:  * or if its {@code run} method completes abruptly and the appropriate
>> 72:  * {@linkplain Thread.UncaughtExceptionHandler uncaught exception handler} completes
>> 73:  * normally or abruptly. With no code left to run, the thread has completed execution.
> 
> I'm in two minds about introducing the UHE in paragraph 3 but probably okay as you kinda have to mention it when defining termination. There's a lot more to this story when you have agents in the picture but I'll not go there. I wonder if we can do something with the last sentence that includes the word "terminated". We use "terminated" in several places and it would be clearer if this sentence were to end with something like "... the thread has completes execution, and is terminated" (it could link to isAlive or Thread.State#TERMINATED).
> 
> Given that the join method is introduced as the method to wait for a thread to terminate then it could be part of this paragraph rather than a single sentence paragraph.

I would also suggest that the join() sentence simply be the last sentence of the above paragraph:

> The join method can be be used to wait for a thread to terminate.

> src/java.base/share/classes/java/lang/Thread.java line 104:
> 
>> 102:  * The <a href="Runtime.html#shutdown">shutdown sequence</a> begins when all started
>> 103:  * non-daemon threads have terminated. Unstarted non-daemon threads do not prevent
>> 104:  * the shutdown sequence from commencing. Invoking the {@linkplain Runtime#exit(int)}
> 
> I think this is the only usage of "commencing", everywhere else uses "beginning" or "begin the shutdown sequence".

"initiated" is also used.

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

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

From dholmes at openjdk.org  Mon Aug  8 02:42:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Aug 2022 02:42:10 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
Message-ID: <CATUkD6iIz_nDhqRE4utJL-BLau0mBbkDqXl6-kaVoc=.780b6f03-66a5-4211-8760-6a62ae249ba0@github.com>

On Mon, 8 Aug 2022 02:34:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 104:
>> 
>>> 102:  * The <a href="Runtime.html#shutdown">shutdown sequence</a> begins when all started
>>> 103:  * non-daemon threads have terminated. Unstarted non-daemon threads do not prevent
>>> 104:  * the shutdown sequence from commencing. Invoking the {@linkplain Runtime#exit(int)}
>> 
>> I think this is the only usage of "commencing", everywhere else uses "beginning" or "begin the shutdown sequence".
>
> "initiated" is also used.

I would suggest saying as little as possible here and simply deferring to the Runtime text ie.:

> The <a href="Runtime.html#shutdown">shutdown sequence</a> begins when all started
non-daemon threads have terminated. 

No need to elaborate, or directly refer to exit().

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

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

From jwaters at openjdk.org  Mon Aug  8 04:49:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 04:49:42 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys
Message-ID: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>

JLI_ReportErrorMessageSys has a number of issues, as listed below:

- The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.

- The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.

- On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.

- Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.

Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

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

Commit messages:
 - Whitespace in Unix variant
 - Improve null termination
 - Fix formatting issues
 - Initial change to JLI_ReportErrorMessageSys

Changes: https://git.openjdk.org/jdk/pull/9793/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292016
  Stats: 66 lines in 4 files changed: 33 ins; 10 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/9793.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793

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

From jwaters at openjdk.org  Mon Aug  8 04:54:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 04:54:03 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v2]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <B290Qay5mPI6L9-Osw_WNMvxhsgkLhTdlg2HeqWFB9w=.222e6498-f32b-4512-a91c-1c25affc22b2@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Try to make Skara happy with comment whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/845d94f0..fcf1f677

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:04:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:04:10 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v3]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <1QDwiRq6WMy-tMp6ctVRZfST5qX88BKGpSnb0Yjav5w=.a14cc1ee-0a90-4bfb-b70f-423927511484@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Small Unix implementation refinement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/fcf1f677..ad74bbd0

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:08:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:08:28 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v4]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <4km1B8MW2ZKGQUPBL5ahVDa0sbNuFPWziKDKfcTrkzU=.d092357e-7079-4b1c-b8ae-10d38c8903c2@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Why does Skara hate me so much

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/ad74bbd0..a0a7948d

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:12:13 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:12:13 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v5]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <WeAMKyiCf67n_80beLvSnkYt0m5fGLHz6xaXQVLj9ik=.9cfe4c81-d685-4f2a-bfcc-7b2db26e2122@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Alright Skara, you win

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/a0a7948d..6175df6e

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:20:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:20:07 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v6]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <5FiaJu3vZjuaLUZbvhmVqWZfBEUZTkfDR2xuLrexFuE=.62ae8e99-3b7b-4563-b25d-049974f66764@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  I don't even know anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/6175df6e..280942d0

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:22:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:22:28 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <v_Jc2p3b0JJ7iHNn731XYqD7ZRWCxUexIUZINITtE8U=.c8cdee6a-84bc-41b7-b862-746a5ed6fd26@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  I feel stupid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/280942d0..e1594dbc

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

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

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

From jwaters at openjdk.org  Mon Aug  8 05:44:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:44:01 GMT
Subject: RFR: 8291454: Missing check for JLI C runtime library in
 CoreLibraries.gmk [v2]
In-Reply-To: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
References: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
Message-ID: <lwTtRsYHeyXqCjfJJAr-_NsITkIUFpITn_WDXDbBY6g=.7e03c6fa-e62c-455f-ae6c-2b7e8853ce23@github.com>

> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect

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-1
 - Add missing check in JLI macro definitions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9669/files
  - new: https://git.openjdk.org/jdk/pull/9669/files/4fb34244..b8c0ea89

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

  Stats: 10452 lines in 526 files changed: 6371 ins; 2832 del; 1249 mod
  Patch: https://git.openjdk.org/jdk/pull/9669.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9669/head:pull/9669

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

From jwaters at openjdk.org  Mon Aug  8 05:44:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:44:03 GMT
Subject: RFR: 8291454: Missing check for JLI C runtime library in
 CoreLibraries.gmk
In-Reply-To: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
References: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
Message-ID: <TR9jL8yKBOhLM1lGgg7k-Nfnis-ISlHoKHw2ERLWEXs=.b1609241-8729-4ada-a2fe-3bb469a225bd@github.com>

On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect

Merged with latest, currently awaiting further review and/or sponsorship

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

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

From alanb at openjdk.org  Mon Aug  8 08:38:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Aug 2022 08:38:03 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>
Message-ID: <quHZr6SN6QmzQsNpBS9_5jlXplwxE2GodozrUFs-XKs=.8a446f53-21a4-403a-80ce-c4f6bd3bb2e1@github.com>

On Fri, 5 Aug 2022 09:54:36 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
>> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
>> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
>> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused JLA, SharedSecrets, added @enablePreview test annotation

Marked as reviewed by alanb (Reviewer).

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

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

From ihse at openjdk.org  Mon Aug  8 08:50:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Aug 2022 08:50:07 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <AXi9Hd7nQT6lsdKur_PCLSykKe0qdFO4akkVazCCWY0=.7e549036-7e5d-44e3-a979-e2afad132efa@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
 <AXi9Hd7nQT6lsdKur_PCLSykKe0qdFO4akkVazCCWY0=.7e549036-7e5d-44e3-a979-e2afad132efa@github.com>
Message-ID: <epycRQG9TJ8ahVYxPNSxX_DCkdlsEEw5EOU595TJF6o=.d802efac-a8d8-4136-a1a3-291836d21664@github.com>

On Fri, 5 Aug 2022 09:55:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Remove unused imports.
>>    
>>    Some imports are no more used.
>>    
>>    - java.io.FileNotFoundException;
>>    - java.io.BufferedInputStream;
>>    - java.io.OutputStream;
>>    - java.util.BitSet;
>>    - java.util.StringTokenizer;
>>    - java.util.Properties;
>>    - java.util.zip.DeflaterOutputStream;
>>    - java.util.zip.Deflater;
>>    - java.net.URL;
>
> You are right, the copyright year on the file is fine - I was looking at an older version of this file.

@jaikiran The build tools are not really part of the build system as such. I used to push for a solution to move them to their corresponding modules, but this met with resistance and did not really go anywhere.

In general, though, the build tools needs to be reviewed by the group "owning" them. In some cases, the change affects how the build tool interacts with the rest of the build system. If that is the case, the build label is relevant.

Unfortunately, the Skara label rules are a bit too coarse to capture this reality.

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

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

From dholmes at openjdk.org  Mon Aug  8 09:10:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Aug 2022 09:10:03 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7]
In-Reply-To: <v_Jc2p3b0JJ7iHNn731XYqD7ZRWCxUexIUZINITtE8U=.c8cdee6a-84bc-41b7-b862-746a5ed6fd26@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <v_Jc2p3b0JJ7iHNn731XYqD7ZRWCxUexIUZINITtE8U=.c8cdee6a-84bc-41b7-b862-746a5ed6fd26@github.com>
Message-ID: <VRMe1GkD4TE5R9kocP5Oi_gVtwKL0QBWoI8lO9LTbec=.ee5af6ec-6df0-4361-be70-fb8c77ec01c5@github.com>

On Mon, 8 Aug 2022 05:22:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>> 
>> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
>> 
>> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
>> 
>> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
>> 
>> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
>> 
>> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   I feel stupid

src/java.base/unix/native/libjli/java_md_common.c line 209:

> 207:     /*
> 208:      * TODO: its safer to use strerror_r but is not available on
> 209:      * Solaris 8. Until then....

We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c

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

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

From alanb at openjdk.org  Mon Aug  8 09:26:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Aug 2022 09:26:22 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
 <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
Message-ID: <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>

On Mon, 8 Aug 2022 00:19:57 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage. And some other performance advantages are there on built-in charset decoder/encoder. Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes? We'd like to use stable conversion loop.

If they have ASCII compatible regions then that may be so but I haven't see any performance data published on that. Do you know if any experiments that have deployed a CharsetProvider for the EBCDIC charsets and compared the performance with the charsets that in the JDK? There may be merit in exploring adding base abstracts implementations of CharsetEncoder/CharsetDecoder to java.nio.charsets.spi to support single and double byte charsets to see how such base implementations might look, how they would help performance, and if there are any security downsides.

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

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

From duke at openjdk.org  Mon Aug  8 11:18:06 2022
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Mon, 8 Aug 2022 11:18:06 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <GExeA_EYNis28Dp6e4RSqAVwPK7GOhoZVNDiJ-ONC68=.5d454dc6-d691-4e62-b324-26be64af53c2@github.com>

On Fri, 5 Aug 2022 16:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
> 
> switch (obj) {
>     case String s when s.isEmpty() -> {}
>     case String s -> {}
>     case CharSequence cs -> {}
>     ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
> 
> obj == null ? -1
>                   : switch (restartIndex) {
>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                         ...
>                         default -> <labels-count>;
>                     }
> 
> 
> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
> 
> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
> 
> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
> 
> 
> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

Would it be possible to add a special case where the labels are all the same type? Like all labels are Class.class or Object.class?
While testing out the pattern matching, I've found myself doing the following


switch (o) {
    case Class<?> c when c == Object.class -> {}
    case Class<?> c when c == Integer.class -> {}
    case Class<?> c when c == String.class -> {}
    case Class<?> c when c == Double.class -> {}
    // ...
}

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

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

From ihse at openjdk.org  Mon Aug  8 12:12:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Aug 2022 12:12:06 GMT
Subject: RFR: 8291454: Missing check for JLI C runtime library in
 CoreLibraries.gmk [v2]
In-Reply-To: <lwTtRsYHeyXqCjfJJAr-_NsITkIUFpITn_WDXDbBY6g=.7e03c6fa-e62c-455f-ae6c-2b7e8853ce23@github.com>
References: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
 <lwTtRsYHeyXqCjfJJAr-_NsITkIUFpITn_WDXDbBY6g=.7e03c6fa-e62c-455f-ae6c-2b7e8853ce23@github.com>
Message-ID: <kJuH1vFYg46C7ZUDYCQewGfsZmkZ4iir6pV81dGLrOc=.28a31473-977a-4177-986c-3ed0f7a5e812@github.com>

On Mon, 8 Aug 2022 05:44:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect
>
> 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-1
>  - Add missing check in JLI macro definitions

Marked as reviewed by ihse (Reviewer).

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

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

From jwaters at openjdk.org  Mon Aug  8 12:14:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 12:14:50 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Whitespace
 - Resolve Windows compile error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/e1594dbc..723557e3

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

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

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

From jwaters at openjdk.org  Mon Aug  8 12:20:34 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 12:20:34 GMT
Subject: Integrated: 8291454: Missing check for JLI C runtime library in
 CoreLibraries.gmk
In-Reply-To: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
References: <Q1d_ayQlDHkEOtae9G4XVY9kV0sNOO5ZwP6jmnR9WIQ=.f7475c64-c14c-49cd-95e2-4422d00964a2@github.com>
Message-ID: <NS8B2f0kgqJtvo1J_bku-3kt82grUl8xINgK0C2SIRg=.f0ee8d10-2932-4d9c-ad2d-d72884efb6c4@github.com>

On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect

This pull request has now been integrated.

Changeset: 8a804f65
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a804f653d21e6e0ed4c1df48a14aa7ad3876dbe
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8291454: Missing check for JLI C runtime library in CoreLibraries.gmk

Reviewed-by: erikj, ihse

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

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

From jwaters at openjdk.org  Mon Aug  8 12:29:09 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 12:29:09 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7]
In-Reply-To: <VRMe1GkD4TE5R9kocP5Oi_gVtwKL0QBWoI8lO9LTbec=.ee5af6ec-6df0-4361-be70-fb8c77ec01c5@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <v_Jc2p3b0JJ7iHNn731XYqD7ZRWCxUexIUZINITtE8U=.c8cdee6a-84bc-41b7-b862-746a5ed6fd26@github.com>
 <VRMe1GkD4TE5R9kocP5Oi_gVtwKL0QBWoI8lO9LTbec=.ee5af6ec-6df0-4361-be70-fb8c77ec01c5@github.com>
Message-ID: <E5VU74UtAF16uuqbZgXm7mPuIUbfbcHt7ZQCVkZdX6Y=.1ca18896-913b-4db6-a1e6-31a6a91d6fac@github.com>

On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   I feel stupid
>
> src/java.base/unix/native/libjli/java_md_common.c line 209:
> 
>> 207:     /*
>> 208:      * TODO: its safer to use strerror_r but is not available on
>> 209:      * Solaris 8. Until then....
> 
> We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c

Looks like the names in jni_util_md.c are also hopelessly inaccurate - what would equate to strlen(strerror_r(errno)) and returns a size_t is named getLastErrorString :P

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

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

From plevart at openjdk.org  Mon Aug  8 12:41:51 2022
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 8 Aug 2022 12:41:51 GMT
Subject: Integrated: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <fADsMdszkdzOld6umODmseDURQCJwfiRQc7obfvyLJI=.c09d0bf9-a8e7-45b0-aa68-4a27d33cfc51@github.com>

On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

This pull request has now been integrated.

Changeset: 861cc671
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/861cc671e2e4904d94f50710be99a511e2f9bb68
Stats:     262 lines in 9 files changed: 196 ins; 12 del; 54 mod

8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)

Reviewed-by: alanb

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

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

From jwaters at openjdk.org  Mon Aug  8 13:21:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 13:21:17 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8]
In-Reply-To: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com>
Message-ID: <J4OxH96H9K9x2s9Q_ubRqwuXsbqqZB9BQy81KfqDOYU=.f4feb282-6aa6-4d63-9ac8-179b4b0efc57@github.com>

On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>> 
>> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
>> 
>> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
>> 
>> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
>> 
>> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
>> 
>> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespace
>  - Resolve Windows compile error

Force push due to some accidental breaking changes

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

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

From jwaters at openjdk.org  Mon Aug  8 13:21:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 13:21:20 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7]
In-Reply-To: <VRMe1GkD4TE5R9kocP5Oi_gVtwKL0QBWoI8lO9LTbec=.ee5af6ec-6df0-4361-be70-fb8c77ec01c5@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <v_Jc2p3b0JJ7iHNn731XYqD7ZRWCxUexIUZINITtE8U=.c8cdee6a-84bc-41b7-b862-746a5ed6fd26@github.com>
 <VRMe1GkD4TE5R9kocP5Oi_gVtwKL0QBWoI8lO9LTbec=.ee5af6ec-6df0-4361-be70-fb8c77ec01c5@github.com>
Message-ID: <7xJ7fc3kv-Qdu9PsisKq9EJjBki02DAGw39pDiqN7dQ=.dcd79a68-440a-4efe-9681-44f37d207cb7@github.com>

On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   I feel stupid
>
> src/java.base/unix/native/libjli/java_md_common.c line 209:
> 
>> 207:     /*
>> 208:      * TODO: its safer to use strerror_r but is not available on
>> 209:      * Solaris 8. Until then....
> 
> We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c

Using getLastErrorString in the implementation for Unix, the Windows version of getLastErrorString is also broken, just like JLI_ErrorMessageSys, but unlike the latter shared code does use it, so no attempts will be made to fix it

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

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

From jwaters at openjdk.org  Mon Aug  8 13:25:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 13:25:22 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <QxenmRgQPso0qgF217V8adfaC1dpKOtyEvINyam37fM=.c0af9330-38e1-4104-9d26-4a4f8117ae70@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  getLastErrorString can be used for Unix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/723557e3..98017b65

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

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

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

From jwaters at openjdk.org  Mon Aug  8 13:25:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 13:25:23 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8]
In-Reply-To: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com>
Message-ID: <ktoIILoUhrPz6CzOvlSmd9xX2g49TD8YQ-Zy7UxdMrA=.14caa93f-3955-42bd-951d-022847c9016d@github.com>

On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>> 
>> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
>> 
>> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
>> 
>> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
>> 
>> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
>> 
>> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespace
>  - Resolve Windows compile error

Sorry bot, made a bit of a mistake...

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

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

From stuefe at openjdk.org  Mon Aug  8 13:51:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 8 Aug 2022 13:51:37 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9]
In-Reply-To: <QxenmRgQPso0qgF217V8adfaC1dpKOtyEvINyam37fM=.c0af9330-38e1-4104-9d26-4a4f8117ae70@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <QxenmRgQPso0qgF217V8adfaC1dpKOtyEvINyam37fM=.c0af9330-38e1-4104-9d26-4a4f8117ae70@github.com>
Message-ID: <jMAKhsaOzHByE-y21wpnA6f9VxYHpM8qPSNHb0xm35A=.7fac8134-131a-41bc-a932-380512bc2112@github.com>

On Mon, 8 Aug 2022 13:25:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>> 
>> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
>> 
>> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
>> 
>> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
>> 
>> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
>> 
>> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   getLastErrorString can be used for Unix

Hi Julien,

Just a tip: as long as you are in the active development phase of a patch, you can mark the PR as "draft". That way you do not spam the mailing lists with updates for every single push. And you save valuable Reviewer cycles since they won't have to look at the half-finished review.

Once you are content with the patch, and all tests are green, you can mark the PR as "ready for review". Only then Review mails are sent out.

---

That said, I don't think printing both codes really works. See my comment in JBS.

Cheers, Thomas

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

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

From jwaters at openjdk.org  Mon Aug  8 14:12:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 14:12:01 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <tIQWS5UpWWu-gHIrtTcNQm_R8Vyc3UU5yNSPDXwAsxY=.c05bd162-4a5d-4bdb-93ec-d22c723afc26@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  How did I even miss this??

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/98017b65..21675f31

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

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

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

From jwaters at openjdk.org  Mon Aug  8 16:25:41 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 16:25:41 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <KyEZNGo43JNWmjsLBzIEuRgPFnTfc8gYV1_reTli7AQ=.3e10e43a-b12c-4bf1-bfa9-f7d2a94e6284@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Include jni_util.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/21675f31..c166e551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=09-10

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

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

From jwaters at openjdk.org  Mon Aug  8 17:15:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 17:15:08 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11]
In-Reply-To: <KyEZNGo43JNWmjsLBzIEuRgPFnTfc8gYV1_reTli7AQ=.3e10e43a-b12c-4bf1-bfa9-f7d2a94e6284@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <KyEZNGo43JNWmjsLBzIEuRgPFnTfc8gYV1_reTli7AQ=.3e10e43a-b12c-4bf1-bfa9-f7d2a94e6284@github.com>
Message-ID: <OW8dXfNaLPI7K8Bqd2VRp5-De3LbH0X__bAaQ82FCvg=.51bfdd01-da1c-4ad5-a1c7-9687bae6918a@github.com>

On Mon, 8 Aug 2022 16:25:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>> 
>> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
>> 
>> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
>> 
>> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
>> 
>> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
>> 
>> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated
>
> Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

Alright Skara, I'm really sorry but don't lynch me for what I'm about to do...

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

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

From jwaters at openjdk.org  Mon Aug  8 18:02:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 18:02:18 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12]
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <QcPlrDuoMpsY7eSbuAYzkhNzW0SxXx1Qq29K-73EgoU=.ea471a6c-f05b-44b7-9a4b-9da80b0f975a@github.com>

> JLI_ReportErrorMessageSys has a number of issues, as listed below:
> 
> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message.
> 
> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist.
> 
> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.
> 
> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself.
> 
> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated

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

  Finalize Unix implementation, Windows to follow after

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9793/files
  - new: https://git.openjdk.org/jdk/pull/9793/files/c166e551..be7d0a9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=10-11

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

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

From sviswanathan at openjdk.org  Mon Aug  8 18:30:17 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 8 Aug 2022 18:30:17 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <gMECIPamcP0kHt7YP7jueXGorBmo2Kg11yxmCmz6BBo=.047049c3-aa47-4aef-b494-0cec4c845c0d@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

src/hotspot/cpu/x86/assembler_x86.cpp line 1927:

> 1925:   assert(VM_Version::supports_evex(), "");
> 1926:   InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /*uses_vl */ true);
> 1927:   attributes.set_is_evex_instruction();

This instruction is supported on AVX (vex encoded) platform as well.
Please rename this as vcvtps2ph and update the check to include supports_evex or supports_f16C. The is_evex_instruction check should then be remvoed.

src/hotspot/cpu/x86/assembler_x86.cpp line 1931:

> 1929:   emit_int8((unsigned char)0x1D);
> 1930:   emit_int8((unsigned char)(0xC0 | encode));
> 1931:   emit_int8(imm8);

You could do emit_int24() here.

src/hotspot/cpu/x86/assembler_x86.cpp line 1937:

> 1935:   assert(VM_Version::supports_evex(), "");
> 1936:   InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */false, /* no_mask_reg */ true, /* uses_vl */ true);
> 1937:   attributes.set_is_evex_instruction();

This instruction is supported on AVX (vex encoded) platform as well.
Please rename this as vcvtph2ps and update the check to include supports_evex or supports_f16C. The is_evex_instruction check should then be remvoed.

src/hotspot/cpu/x86/x86.ad line 1686:

> 1684:     case Op_ConvHF2F:
> 1685:       if (!VM_Version::supports_evex() || !VM_Version::supports_avx512vl()) {
> 1686:         return false;

Please include supports_f16c here.

src/hotspot/cpu/x86/x86_64.ad line 11310:

> 11308: 
> 11309: instruct convF2HF_reg_reg(rRegI dst, regF src, regF tmp) %{
> 11310:   predicate(VM_Version::supports_evex());

The predicate could be removed as the check is fully done in match_rule_supported.

src/hotspot/cpu/x86/x86_64.ad line 11313:

> 11311:   effect(TEMP tmp);
> 11312:   match(Set dst (ConvF2HF src));
> 11313:   format %{ "evcvtps2ph $dst,$src" %}

It will be good to also show the tmp register in the format.

src/hotspot/cpu/x86/x86_64.ad line 11323:

> 11321: 
> 11322: instruct convHF2F_reg_reg(regF dst, rRegI src) %{
> 11323:   predicate(VM_Version::supports_evex());

The predicate could be removed as it is fully covered in the match_rule_supported.

src/hotspot/share/opto/convertnode.cpp line 251:

> 249: //------------------------------Identity---------------------------------------
> 250: Node* ConvHF2FNode::Identity(PhaseGVN* phase) {
> 251:   return (in(1)->Opcode() == Op_ConvF2HF) ? in(1)->in(1) : this;

We cannot do this optimization:
     HF2F(F2HF(x)) != x 
This is because precision and range both are lost when we convert F2HF.

src/hotspot/share/opto/convertnode.hpp line 150:

> 148:   virtual const Type *bottom_type() const { return Type::FLOAT; }
> 149:   virtual const Type* Value(PhaseGVN* phase) const;
> 150:   virtual Node* Identity(PhaseGVN* phase);

The identity method could be removed from ConvHF2FNode

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

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

From sviswanathan at openjdk.org  Mon Aug  8 18:30:18 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 8 Aug 2022 18:30:18 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <VDTS0Z_Dq3_gWsf2m8MCXNJ5P32gMrYk5NWclaJDUJM=.d8bd97e2-4071-4643-a9f3-b862fe0d3fb8@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <FVlk5e833tCEIn7ugNEK910_C_xrbVk4pwYkC0klBY0=.77ec5cee-6ad5-4b30-b44f-9da4ceaf7081@github.com>
 <NzqmdqoUw-ofeJeiiht3Z9Qymp0Tt2fCM14FOrp_uFk=.8f9568da-c471-4668-9bd0-96bfc26454d2@github.com>
 <VDTS0Z_Dq3_gWsf2m8MCXNJ5P32gMrYk5NWclaJDUJM=.d8bd97e2-4071-4643-a9f3-b862fe0d3fb8@github.com>
Message-ID: <j1SddtR1w5b61neUia-5EWsHIOooOOLN6Qdc-2FlrAs=.8ddad89b-df7d-4e55-8995-bb09940f0f54@github.com>

On Fri, 5 Aug 2022 23:58:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here.
>
> I was under the impression that if a platform didn't have special support for the functionality in question it could not have the intrinsic and just use the Java library implementation?

@jddarcy This code is for constant expression evaluation during C2 compilation.

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

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

From akasko at openjdk.org  Mon Aug  8 18:39:01 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 18:39:01 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
Message-ID: <v4YOLaxNX8HsbFBOgFsX46wVUWAmJsG40wKiuhvq1oY=.78784a45-991c-417b-a977-8c36b4f4204f@github.com>

On Fri, 5 Aug 2022 17:04:54 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reg method access, drop l10n entries, label check enhancement

Thanks for the l10n files review! As I understand, I need a second jpackage-specific review before integrating the change. I can change non-EN `.wxl` files as needed - please confirm if they need to be changed.

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

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

From akasko at openjdk.org  Mon Aug  8 18:42:15 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 18:42:15 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <uF_7eX2Pa1zbWd_z89og8tY6YfjhsFzkPev1uRMhjuU=.d8d34098-2112-43db-96ec-3d44a7f55ec7@github.com>

On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

Thanks for the review!

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

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

From asemenyuk at openjdk.org  Mon Aug  8 18:54:15 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 8 Aug 2022 18:54:15 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <vVEHVguD1D_BW1FTuznHEU-P0P1TDTV-7-8LsOHfh6U=.441bd18a-6168-4a43-86a2-526e6e50a3be@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
 <vVEHVguD1D_BW1FTuznHEU-P0P1TDTV-7-8LsOHfh6U=.441bd18a-6168-4a43-86a2-526e6e50a3be@github.com>
Message-ID: <bI-oxWw-zgKOt31u2JURE1kASQZmqvNdHHqRl3RZZ6c=.e84a55a7-47bc-45bd-9f21-6214cd75d107@github.com>

On Sat, 6 Aug 2022 13:48:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reg method access, drop l10n entries, label check enhancement
>
> Missing entries in localized files are automatically detected by the translation process. So modifying only the English file should be fine.

@naotoj , I suspect missing entries in l10n files will cause code depending on them to fail when executed in non-English locales until the next l10n drop corrects missing entries.

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

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

From duke at openjdk.org  Mon Aug  8 19:00:54 2022
From: duke at openjdk.org (Max Mielchen)
Date: Mon, 8 Aug 2022 19:00:54 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
Message-ID: <nyhRr_74g9xeUcuDy2wE1oYoS57aGZosNbDGKlS8KSI=.af20812b-9657-4d02-b46d-1ee55de93d40@github.com>

On Sat, 6 Aug 2022 14:55:17 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>    
>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Inline max Integer.stringSize
>  - Estimate length
>  - Address comments
>  - Precompute StackTraceElement toString length
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Optimize StackTraceElement.toString()
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/ea20ba0f...c9ae3897

Marked as reviewed by maxmielchen at github.com (no known OpenJDK username).

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

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

From naoto at openjdk.org  Mon Aug  8 19:02:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Aug 2022 19:02:15 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <bI-oxWw-zgKOt31u2JURE1kASQZmqvNdHHqRl3RZZ6c=.e84a55a7-47bc-45bd-9f21-6214cd75d107@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
 <vVEHVguD1D_BW1FTuznHEU-P0P1TDTV-7-8LsOHfh6U=.441bd18a-6168-4a43-86a2-526e6e50a3be@github.com>
 <bI-oxWw-zgKOt31u2JURE1kASQZmqvNdHHqRl3RZZ6c=.e84a55a7-47bc-45bd-9f21-6214cd75d107@github.com>
Message-ID: <qSJLv7Gp2hU0a9OdqDRqoR2obNnKovRQqIlQNRGriRQ=.6d474e30-587b-4dfd-9461-879779eea940@github.com>

On Mon, 8 Aug 2022 18:51:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Missing entries in localized files are automatically detected by the translation process. So modifying only the English file should be fine.
>
> @naotoj , I suspect missing entries in l10n files will cause code depending on them to fail when executed in non-English locales until the next l10n drop corrects missing entries.

Thanks, @alexeysemenyukoracle , I was under the impression of falling back to the English resource if l10n was not available. If it is not falling back to English,  please bring those non-English resources back.

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

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

From akasko at openjdk.org  Mon Aug  8 19:52:41 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 19:52:41 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v3]
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

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

  add english entries to l10n files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9753/files
  - new: https://git.openjdk.org/jdk/pull/9753/files/227ad5d4..ff3d8ae2

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

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

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

From akasko at openjdk.org  Mon Aug  8 19:52:42 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 19:52:42 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v2]
In-Reply-To: <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <0eh4x2q7ukIqRnriFOS3sjpVqKlre8Ns146xTgyi3ls=.d114a92e-78d3-4dd9-a9dd-d6583c223432@github.com>
Message-ID: <_QwBs8ud6uYj3cOtKJjL8HZgcK0HaaYZjc6vWZ7ZgTM=.bb336dce-4e10-4cc4-ba18-d1bd98d8ceec@github.com>

On Fri, 5 Aug 2022 17:04:54 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reg method access, drop l10n entries, label check enhancement

Thanks for clarification! I've updated the patch adding English entries to all `.wxl` files.

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

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

From lmesnik at openjdk.org  Mon Aug  8 20:02:24 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Aug 2022 20:02:24 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false"
Message-ID: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>

The test should use the same locales in all processes, the default language should work fine.

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

Commit messages:
 - 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false"

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

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

From almatvee at openjdk.org  Mon Aug  8 20:36:16 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Aug 2022 20:36:16 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <6w8Vd6YpJU-o5fsRNPUYS80FAIwrpWBeV0-K2kOCzRg=.226594b5-4248-4390-bbdb-e23d1e2eb310@github.com>

On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

Marked as reviewed by almatvee (Reviewer).

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

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

From almatvee at openjdk.org  Mon Aug  8 20:43:08 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Aug 2022 20:43:08 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <2j8o_jyvjR9KLicct0-49DDeY0HNKkUXnQF6ctEogCU=.722f3697-ba19-4e2a-8742-2e7b791e23e7@github.com>

On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 37:

> 35: resource.post-app-image-script=script to run after application image is populated
> 36: resource.post-msi-script=script to run after msi file for exe installer is created
> 37: resource.wxl-file=WiX localization file

This needs to be added to all WinResources*.properties files.

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

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

From asemenyuk at openjdk.org  Mon Aug  8 21:09:39 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 8 Aug 2022 21:09:39 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <2j8o_jyvjR9KLicct0-49DDeY0HNKkUXnQF6ctEogCU=.722f3697-ba19-4e2a-8742-2e7b791e23e7@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <2j8o_jyvjR9KLicct0-49DDeY0HNKkUXnQF6ctEogCU=.722f3697-ba19-4e2a-8742-2e7b791e23e7@github.com>
Message-ID: <2YNK7O88bG8nX6tyaai3dqMT8S5ZTNZwr9skjYPLmxw=.af59871b-86ee-4bcc-aec8-70d03d401517@github.com>

On Mon, 8 Aug 2022 20:39:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 37:
> 
>> 35: resource.post-app-image-script=script to run after application image is populated
>> 36: resource.post-msi-script=script to run after msi file for exe installer is created
>> 37: resource.wxl-file=WiX localization file
> 
> This needs to be added to all WinResources*.properties files.

Good point. We have a discussion of how l10n files should be changed at https://github.com/openjdk/jdk/pull/9753. Can you confirm that if some property is missing in a resource bundle its value is picked from the English resource bundle?

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

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

From asemenyuk at openjdk.org  Mon Aug  8 21:09:41 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 8 Aug 2022 21:09:41 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v3]
In-Reply-To: <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
Message-ID: <0WMT9ASt1KU8g3b3ptF5GElWk-k_eVhYzKhnwpHi5Z0=.15aa28e9-7628-403d-868c-524af566e7e8@github.com>

On Mon, 8 Aug 2022 19:52:41 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add english entries to l10n files

Marked as reviewed by asemenyuk (Reviewer).

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

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

From akasko at openjdk.org  Mon Aug  8 21:21:07 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 21:21:07 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v2]
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <pOmjDoTpyjLf5faPHnRY9_tVe1SoAGh34HjCsv-wsr0=.969109ce-c1e8-4230-9f9d-7604da8fd2d8@github.com>

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

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

  add english entries to all l10n files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9780/files
  - new: https://git.openjdk.org/jdk/pull/9780/files/d4ba8bf0..097ae46e

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

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

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

From asemenyuk at openjdk.org  Mon Aug  8 21:21:07 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 8 Aug 2022 21:21:07 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v2]
In-Reply-To: <pOmjDoTpyjLf5faPHnRY9_tVe1SoAGh34HjCsv-wsr0=.969109ce-c1e8-4230-9f9d-7604da8fd2d8@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <pOmjDoTpyjLf5faPHnRY9_tVe1SoAGh34HjCsv-wsr0=.969109ce-c1e8-4230-9f9d-7604da8fd2d8@github.com>
Message-ID: <9YHlAqF8PZGGlMlEnxoSQsKMMJQzGY3ponw-SNzU678=.2af46c95-e300-41f2-a7bf-8ffab3352c09@github.com>

On Mon, 8 Aug 2022 21:10:26 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add english entries to all l10n files

Marked as reviewed by asemenyuk (Reviewer).

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

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

From akasko at openjdk.org  Mon Aug  8 21:21:08 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Mon, 8 Aug 2022 21:21:08 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v2]
In-Reply-To: <2YNK7O88bG8nX6tyaai3dqMT8S5ZTNZwr9skjYPLmxw=.af59871b-86ee-4bcc-aec8-70d03d401517@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <2j8o_jyvjR9KLicct0-49DDeY0HNKkUXnQF6ctEogCU=.722f3697-ba19-4e2a-8742-2e7b791e23e7@github.com>
 <2YNK7O88bG8nX6tyaai3dqMT8S5ZTNZwr9skjYPLmxw=.af59871b-86ee-4bcc-aec8-70d03d401517@github.com>
Message-ID: <VI9XVRXOeheWOdjul7YAqet5fd2W7qJnj6GjO5iRcp0=.7b337553-7e01-4c81-89cf-ff50c1686551@github.com>

On Mon, 8 Aug 2022 21:04:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 37:
>> 
>>> 35: resource.post-app-image-script=script to run after application image is populated
>>> 36: resource.post-msi-script=script to run after msi file for exe installer is created
>>> 37: resource.wxl-file=WiX localization file
>> 
>> This needs to be added to all WinResources*.properties files.
>
> Good point. We have a discussion of how l10n files should be changed at https://github.com/openjdk/jdk/pull/9753. Can you confirm that if some property is missing in a resource bundle its value is picked from the English resource bundle?

I've just pushed the commit with EN entries for all files before reading the latest comment. I'll verify the behaviour with `.wxl` and `.properties` files and will comment in this issue.

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

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

From almatvee at openjdk.org  Mon Aug  8 21:24:05 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Aug 2022 21:24:05 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v3]
In-Reply-To: <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
Message-ID: <fAEhAAbbWOFOaNbT7g5IZU2marbzf9igp-rO3h7NKk4=.8f2f2477-a4c0-4f69-aa22-740be12ec223@github.com>

On Mon, 8 Aug 2022 19:52:41 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add english entries to l10n files

Marked as reviewed by almatvee (Reviewer).

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

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

From naoto at openjdk.org  Mon Aug  8 21:26:53 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Aug 2022 21:26:53 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v2]
In-Reply-To: <VI9XVRXOeheWOdjul7YAqet5fd2W7qJnj6GjO5iRcp0=.7b337553-7e01-4c81-89cf-ff50c1686551@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <2j8o_jyvjR9KLicct0-49DDeY0HNKkUXnQF6ctEogCU=.722f3697-ba19-4e2a-8742-2e7b791e23e7@github.com>
 <2YNK7O88bG8nX6tyaai3dqMT8S5ZTNZwr9skjYPLmxw=.af59871b-86ee-4bcc-aec8-70d03d401517@github.com>
 <VI9XVRXOeheWOdjul7YAqet5fd2W7qJnj6GjO5iRcp0=.7b337553-7e01-4c81-89cf-ff50c1686551@github.com>
Message-ID: <OVafzuvVPaq5mhE4mz4J4GDvKIJzKovjx4zNwu1Z_cw=.bdcfd66b-cdeb-4165-bfa2-48aa4874c944@github.com>

On Mon, 8 Aug 2022 21:10:26 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> Good point. We have a discussion of how l10n files should be changed at https://github.com/openjdk/jdk/pull/9753. Can you confirm that if some property is missing in a resource bundle its value is picked from the English resource bundle?
>
> I've just pushed the commit with EN entries for all files before reading the latest comment. I'll verify the behaviour with `.wxl` and `.properties` files and will comment in this issue.

I believe for the `.properties` case, modifications for the localized files are not required, as ResourceBundles fall back to the root (English) bundle.

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

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

From cjplummer at openjdk.org  Mon Aug  8 21:34:53 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Aug 2022 21:34:53 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false"
In-Reply-To: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>

On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test should use the same locales in all processes, the default language should work fine.

Can you explain why setting the locale on the test but not the subprocess is causing the failure?

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

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

From lmesnik at openjdk.org  Mon Aug  8 21:43:54 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 Aug 2022 21:43:54 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false"
In-Reply-To: <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>
Message-ID: <cFZuplchsd1iHDcUxiZT24nOyGqf8Cb7lSO0u_Tl17k=.4f693b06-d265-487e-bd56-ce3d2b7f3dd2@github.com>

On Mon, 8 Aug 2022 21:31:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Can you explain why setting the locale on the test but not the subprocess is causing the failure?

The jstatd process prints some numbers always using "en" locale and "." as decimal separators. While reading process might have different locale  ("vi" for example) and use "," as a decimal separator. So test fails to parse such numbers.

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

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

From kevinw at openjdk.org  Mon Aug  8 21:52:24 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Aug 2022 21:52:24 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false"
In-Reply-To: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <hgiTn0ZzybaQwxqWdhMcyAR8z6JnZfSKh5GKKi4qEXU=.4666e78e-12d9-46f8-8392-f9ac9ded4933@github.com>

On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test should use the same locales in all processes, the default language should work fine.

I tried a few locales and could not reproduce the problem, I was expecting some kind of mismatch would trigger it, but not sure what to set where to cause this...

Something else I noticed while looking however: I looked at JstatGCUtilParser.java / verify(String... valueArray)
I see it checks values are of the right type: but after almost all checks, it does a "break",
so stops iterating values.
Only percentage checks permit checking to continue. 8-)
There are three "break" statements in verify(String... valueArray) which should be "continue".
We can handle that in a separate issue.

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

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

From smarks at openjdk.org  Mon Aug  8 22:03:21 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:03:21 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
Message-ID: <h2HsStYNpnKk1KOdQQGShMXeJzL-rDFOP5thWT3cRP8=.df6775d6-5208-4361-8450-a7dda344ad05@github.com>

On Sat, 6 Aug 2022 07:47:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More edits from Alex's suggestions.
>
> src/java.base/share/classes/java/lang/System.java line 1888:
> 
>> 1886:      * Initiates the <a href="Runtime.html#shutdown">shutdown sequence</a> of the Java Virtual
>> 1887:      * Machine. This method always blocks indefinitely. The
>> 1888:      * argument serves as a status code; by convention, a nonzero status
> 
> Would you remind reflowing this one too as the latest change means lines length are inconsistent.

Will do.

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

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

From smarks at openjdk.org  Mon Aug  8 22:08:19 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:08:19 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <CATUkD6iIz_nDhqRE4utJL-BLau0mBbkDqXl6-kaVoc=.780b6f03-66a5-4211-8760-6a62ae249ba0@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
 <CATUkD6iIz_nDhqRE4utJL-BLau0mBbkDqXl6-kaVoc=.780b6f03-66a5-4211-8760-6a62ae249ba0@github.com>
Message-ID: <ea0uhvlaoO_qIekbegbTqytLKSYK3nvo2r_z23cfmqU=.f1620c3a-2b7c-4837-80ac-12626b09dd07@github.com>

On Mon, 8 Aug 2022 02:36:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> "initiated" is also used.
>
> I would suggest saying as little as possible here and simply deferring to the Runtime text ie.:
> 
>> The <a href="Runtime.html#shutdown">shutdown sequence</a> begins when all started
> non-daemon threads have terminated. 
> 
> No need to elaborate, or directly refer to exit().

I changed "commencing" to beginning, and I removed the sentence talking about Runtime::exit. I think it's useful to be explicit about unstarted non-daemon threads.

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

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

From forax at univ-mlv.fr  Mon Aug  8 22:24:16 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 9 Aug 2022 00:24:16 +0200 (CEST)
Subject: More elegant multi-condition groupby. #9719
In-Reply-To: <tencent_B10507A99263306440A045739A77D8969309@qq.com>
References: <tencent_B10507A99263306440A045739A77D8969309@qq.com>
Message-ID: <915511957.19941820.1659997456780.JavaMail.zimbra@u-pem.fr>

> From: "(11I10I24) ? ? ? ?" <1015770492 at qq.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Saturday, August 6, 2022 11:49:18 AM
> Subject: More elegant multi-condition groupby. #9719

> Hi, team

> I have two suggestions

> Firstly:

> If we can provide a new API for grouping ( java.util.stream.Collectors )
> such as:
> userList.stream().collect(Collectors.groupingBy(User::getName, User::getCity))
> userList.stream().collect(Collectors.groupingBy("-", User::getName,
> User::getCity, User::getId));// key is "name-city", value is List after being
> grouped

> It helps us to do grouping with less code. and It looks cooler for lambda.

> And I've provided a simple demo.
> demo:
> https://github.com/1015770492/CollectorsDemo/blob/master/src/main/java/com/example/demo/MultiGroupByDemo.java
> issue: https://github.com/openjdk/jdk/pull/9719

> Secondly:

> similarly, if we can provide new api for sort with stream.
> It can be?
> userList.stream().sorted(User::getAge)
> or userList.stream().sorted(User::getName)
> or userList.stream().sorted(User::getName, User::getAge)

> userList.stream().sorted(User::getAge) age is a Integer or int type ,it is
> Comparable, So if we can use the Function reference implements sort.

> String implements the Comparable Interface but we do not use the features.

> userList.stream().sorted(User::getCity, User::getName)
> multi-condition sort we can transfor to String sort.

Hi ! 
we usually add additional APIs because it's cooler :) 

If i understand you correctly, you are saying that from a user POV dealing with composite keys for grouping or sorting could be improved. 

I really do not like you first proposal because you are introducing a String where you could introduce a real object (the composite key), here string acting as a cheaper inferior object. 
Using a record seems to be a better idea (technically what we want here is tuples but records is good enough) 
record CompositeKey(String name, int age) { } 

so you can write 
list.stream().collect(groupingBy(user -> new CompositeKey(user.getName, user.getAge()))) 
and with a static method in CompositeKey 
record CompositeKey(String name, int age) { 
static CompositeKey fromUser(User user) { return new CompositeKey(user.getName, user.getAge()); } 
} 

it can be simplified to 
list.stream().collect(groupingBy(CompositeKey::fromUser)) 

For sorting, it's a different, the API you propose has already have been proposed and rejected during the development of Java 8 
Comparing using Integer instead of int is really slow, so we do not want users to be forced to box things. 
The API you propose requires the return type of User::getCity and the return type User::getAge to be inferred as the same type variable, sadly it means boxing, so it's not a good API. 

> best regards
> Yu, Jinhua
> 1015770492 at qq.com

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220809/0d9f0d75/attachment-0001.htm>

From smarks at openjdk.org  Mon Aug  8 22:39:21 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:39:21 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
Message-ID: <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>

On Mon, 8 Aug 2022 02:33:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 73:
>> 
>>> 71:  * or if its {@code run} method completes abruptly and the appropriate
>>> 72:  * {@linkplain Thread.UncaughtExceptionHandler uncaught exception handler} completes
>>> 73:  * normally or abruptly. With no code left to run, the thread has completed execution.
>> 
>> I'm in two minds about introducing the UHE in paragraph 3 but probably okay as you kinda have to mention it when defining termination. There's a lot more to this story when you have agents in the picture but I'll not go there. I wonder if we can do something with the last sentence that includes the word "terminated". We use "terminated" in several places and it would be clearer if this sentence were to end with something like "... the thread has completes execution, and is terminated" (it could link to isAlive or Thread.State#TERMINATED).
>> 
>> Given that the join method is introduced as the method to wait for a thread to terminate then it could be part of this paragraph rather than a single sentence paragraph.
>
> I would also suggest that the join() sentence simply be the last sentence of the above paragraph:
> 
>> The join method can be be used to wait for a thread to terminate.

The whole paragraph is about thread termination, so I don't think we need to say "terminate" again in the last sentence. We could mention isAlive or the TERMINATED state, but that brings in Thread.State which which require a discussion of the thread's life cycle.

The "join" sentence was kind of tacked on to the end of a paragraph in the original text; Alex suggested that I separate it into its own paragraph when we were working on the "termination" paragraph. Alex doesn't mind single-sentence paragraphs, which isn't my preference. But tacking the "join" sentence onto the end of the "termination" paragraph actually doesn't make any sense. Termination is something that happens to _this_ thread. The join method is called from _another_ thread, and this implicit shift of viewpoint would weaken the paragraph.

Frankly I think there needs to be a separate editorial pass over the Thread docs. I know they were just rewritten in JDK 19, but there are some odd things about it. The Thread.State life cycle isn't explained and isn't referenced by methods such as start() and isAlive(). Also, various mentions of uncaught exception handling talk about a thread's abrupt termination. There isn't any such thing; a _method_ can complete normally or abruptly, and when a thread's run() method completes either way, the thread simply terminates.

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

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

From smarks at openjdk.org  Mon Aug  8 22:49:20 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:49:20 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
Message-ID: <NJ2Lu2GIKudZNaQBdDxXdpuJf7687oJBBRiK4pGvkvE=.3eec9cec-ffb1-4105-a33a-992b306b4882@github.com>

On Mon, 8 Aug 2022 01:55:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More edits from Alex's suggestions.
>
> src/java.base/share/classes/java/lang/Runtime.java line 66:
> 
>> 64:  * {@linkplain Thread#start started} in some unspecified order. They run concurrently
>> 65:  * with any daemon or non-daemon threads that were {@linkplain Thread#isAlive() alive}
>> 66:  * at the beginning of the shutdown sequence.
> 
> or which subsequently get started as covered later. So perhaps a simple reordering here:
> 
>> <p>At the beginning of the shutdown sequence, the registered shutdown hooks are  {@linkplain Thread#start started} in some unspecified order.
> 
>> <p>After the shutdown sequence has begun, registration and de-registration of shutdown hooks with {@link #addShutdownHook addShutdownHook} and {@link #removeShutdownHook removeShutdownHook} is prohibited. However, creating and starting new threads is permitted.
> 
>> <p> The shutdown hooks run concurrently with any daemon or non-daemon threads that were {@linkplain Thread#isAlive() alive} at the beginning of the shutdown sequence; or which are subsequently started.

Alex and I have gone over this about three times. Your suggestion is shorter, but it requires a closer read to see all the cases. In particular, it answers the questions "what happens to currently running threads" and specifically mentions both daemon and non-daemon threads. Various earlier bits of text implied incorrectly that non-daemon threads could no longer be running during the shutdown sequence or even at the end of the shutdown sequence. Being explicit makes things somewhat redundant but it covers the cases more thoroughly.

> src/java.base/share/classes/java/lang/Runtime.java line 85:
> 
>> 83:  * effect on the shutdown sequence is unspecified.
>> 84:  *
>> 85:  * <h2><a id="termination">Virtual Machine Termination</a></h2>
> 
> Should this say "Java Virtual Machine Termination" for consistency.

will fix

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

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

From smarks at openjdk.org  Mon Aug  8 22:59:33 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:59:33 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v5]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <ezYz_s8SKOP0suG8aGtlLuRMftXnNp0vY8K0BKZ6FJc=.96f6c33f-79a4-4d28-94e0-74c8b36f9871@github.com>

> Initial edits to addShutdownHook from Alex.
> 
> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Updates from Alan, David, and Alex.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/d348cca4..c8b331f1

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

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

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

From smarks at openjdk.org  Mon Aug  8 22:59:37 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 Aug 2022 22:59:37 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
Message-ID: <IRFbuqqdE4msAd-xH3WLVuZDV9Vz-F3G1J3Ooj_SWLI=.c6f96d9a-ca63-4df1-b3ce-68103dbd4202@github.com>

On Mon, 8 Aug 2022 02:06:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More edits from Alex's suggestions.
>
> src/java.base/share/classes/java/lang/Runtime.java line 55:
> 
>> 53:  * to one of several events:
>> 54:  * <ol>
>> 55:  * <li>when the number of {@linkplain Thread#isAlive() live} non-daemon threads drops to zero
> 
> Can we somehow forward-reference the implNote about DestroyJavaVM here?

added

> src/java.base/share/classes/java/lang/Runtime.java line 99:
> 
>> 97:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">DestroyJavaVM</a>.
>> 98:  * This function is responsible for initiating the shutdown sequence when the number of running
>> 99:  * ({@linkplain Thread#isAlive() live}) non-daemon threads first drops to zero. When the shutdown
> 
> I think we need to align this more with the proposed text of JLS 12.8. It needs to be clearer that `DestroyJavaVM` must be used in conjunction with `CreateJavaVM` to get the desired termination behaviour. Otherwise, the proposed text allows for the possibility that the JVM will always terminate when the last non-daemon thread terminates, even if `DestroyJavaVM` has not been called. It needs to be clear that if the JVM is started by the JNI Invocation API, then it must also be terminated by the JNI invocationAPI to get the required behaviour.

OK, yes I accept the general premise of your comment. Indeed we need to make sure this section is well aligned with JLS 12.8 (as well as the JNI spec and the JVMS, though I think those can be a bit more distant). I see that Alex has updated JLS 12.8 more recently than your comment, so I'll hold off editing this section for now and check with him to make sure he's done editing before I proceed. We might need some additional discussion as well. So, more to come.

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

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

From forax at univ-mlv.fr  Mon Aug  8 23:03:21 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 9 Aug 2022 01:03:21 +0200 (CEST)
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <fXPmtVVPgwvQQShWq63_eq3-9bZNa24__bfW_Pq1Zgg=.0a1728bc-2017-4acd-b04f-14ba2f7c12bf@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <1385192326.19042988.1659720889055.JavaMail.zimbra@u-pem.fr>
 <fXPmtVVPgwvQQShWq63_eq3-9bZNa24__bfW_Pq1Zgg=.0a1728bc-2017-4acd-b04f-14ba2f7c12bf@github.com>
Message-ID: <413017628.19956169.1659999801502.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Jan Lahoda" <jlahoda at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, August 5, 2022 11:03:06 PM
> Subject: Re: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster

> On Fri, 5 Aug 2022 20:20:56 GMT, Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> You only need restart index at the beginning and after a when, so in your
>> example, only 0 and 1 are required, you can skip the generation of 2 because
>> you will never restart at 2.
>> 
> 
> The bootstrap protocol does not specify which cases have guards, so I don't
> think the bootstrap cannot do such a decision.

ahh, double negation :)

the bootstrap protocol can be updated as it please you no ? 

R?mi

From darcy at openjdk.org  Tue Aug  9 00:33:56 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 Aug 2022 00:33:56 GMT
Subject: RFR: JDK-8291734: Return accurate ACC_SUPER access flag for classes
Message-ID: <KmGecD-ymlfsIy5mkToGcewYABclZs7OksOVQ_CysGw=.09665f4f-ae31-435d-aff5-af82e1a5f6a0@github.com>

With the ACC_SUPER information now available from a private getClassAccessFlagsRaw() method, the 
 Set<AccessFlag> accessFlags() 
method can properly model that setting.

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

Commit messages:
 - JDK-8291734: Return accurate ACC_SUPER access flag for classes

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

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

From joehw at openjdk.org  Tue Aug  9 00:59:19 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Aug 2022 00:59:19 GMT
Subject: RFR: JDK-8290836 Improve test coverage for XPath functions: String
 Functions [v2]
In-Reply-To: <wR1bywsMZEP6yBVWDOcB40WuqwWbw7Eogv-tH2NSq8g=.7179d88e-a211-4d8a-a160-7c8083d32c0b@github.com>
References: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
 <wR1bywsMZEP6yBVWDOcB40WuqwWbw7Eogv-tH2NSq8g=.7179d88e-a211-4d8a-a160-7c8083d32c0b@github.com>
Message-ID: <osq-N1J5ZQrt7zlefupbFmNkwrF0hetZJSrT97QC7lQ=.3f2ef8d5-fad4-4c5a-b09e-f9dfbd323463@github.com>

On Fri, 5 Aug 2022 18:30:05 GMT, Bill Huang <duke at openjdk.org> wrote:

>> Improve test coverage for XPath functions: [JDK-8290836](https://bugs.openjdk.org/browse/JDK-8290836), [JDK-8290837](https://bugs.openjdk.org/browse/JDK-8290837), [JDK-8290838](https://bugs.openjdk.org/browse/JDK-8290838).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments and fixed typo.

Thanks for the update.

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

Marked as reviewed by joehw (Reviewer).

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

From lmesnik at openjdk.org  Tue Aug  9 02:35:14 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Aug 2022 02:35:14 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false" [v2]
In-Reply-To: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>

> The test should use the same locales in all processes, the default language should work fine.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9798/files
  - new: https://git.openjdk.org/jdk/pull/9798/files/b7491b7d..50c562dc

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

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

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

From lmesnik at openjdk.org  Tue Aug  9 02:38:28 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Aug 2022 02:38:28 GMT
Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with
 "Not a percentage\: 68.31\: expected true, was false" [v2]
In-Reply-To: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>
Message-ID: <ouvVr2cvwgMorZnRwLwLK4HkjAQC-0kN2xzgAWle2dE=.98635408-aef0-4c95-a4a3-f21c659c1ffb@github.com>

On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test should use the same locales in all processes, the default language should work fine.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

> I tried a few locales and could not reproduce the problem, I was expecting some kind of mismatch would trigger it, but not sure what to set and where to cause this...

It is needed to verify that the locale in java has been changed and that not G1 is used. The G1 'S0' is 0.00 which is zero for all locales and test passe because of your issue. I used additional logs to check that locale was actually updated.


Also, it is needed to see language with "," as a decimal delimiter.


> 
> Something else I noticed while looking, however: I looked at JstatGCUtilParser.java / verify(String... valueArray) I see it checks values are of the right type: but after almost all checks, it does a "break", so stops iterating values. Only percentage checks permit checking to continue. 8-) There are three "break" statements in verify(String... valueArray) which should be "continue". We can handle that in a separate issue.

Thank you! that explains a lot! I've updated the fix.

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

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

From jpai at openjdk.org  Tue Aug  9 02:39:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 02:39:39 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
Message-ID: <HTa4MxlqtxoLLKKpupFtl3Xfg6wzXJhMYdoyjxgQXuw=.8b2cc1e3-d39c-4965-a5b6-a4a0d2c02ceb@github.com>

On Fri, 5 Aug 2022 08:59:00 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is tracked in JBS as
>> 
>> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
>> 
>> Unused imports in DTDBuider.java.
>> 
>>> **Remove unused imports from DTDBuilder.java**
>> 
>> Some imports are no more used.
>> 
>> - java.io.FileNotFoundException;
>> - java.io.BufferedInputStream;
>> - java.io.OutputStream;
>> - java.util.BitSet;
>> - java.util.StringTokenizer;
>> - java.util.Properties;
>> - java.util.zip.DeflaterOutputStream;
>> - java.util.zip.Deflater;
>> - java.net.URL;
>> 
>> https://github.com/scientificware/jdk/issues/4
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Remove unused imports.
>    
>    Some imports are no more used.
>    
>    - java.io.FileNotFoundException;
>    - java.io.BufferedInputStream;
>    - java.io.OutputStream;
>    - java.util.BitSet;
>    - java.util.StringTokenizer;
>    - java.util.Properties;
>    - java.util.zip.DeflaterOutputStream;
>    - java.util.zip.Deflater;
>    - java.net.URL;

Marked as reviewed by jpai (Reviewer).

Thank you Magnus.

Given the nature of this change, adding myself as the reviewer and approving this change.

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

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

From jpai at openjdk.org  Tue Aug  9 02:39:40 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 02:39:40 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2]
In-Reply-To: <uChH4TsDs7SA5xbTBSfrzP4Rlk7ghHiKAOzSJ15jzgY=.d30e91a0-df94-45a0-baa8-9a7c548ca213@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
 <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>
 <daorXu_NRyh6_DWKilgiwi3BJTB-vYOFcu7jhEpjRxg=.22750241-e53d-410b-9c83-4051b16ce644@github.com>
 <uChH4TsDs7SA5xbTBSfrzP4Rlk7ghHiKAOzSJ15jzgY=.d30e91a0-df94-45a0-baa8-9a7c548ca213@github.com>
Message-ID: <DVnDiU08bGVW5rNORbGY2dI0d8L5MEzn7SNNwmv-syw=.2b488214-1f6f-4897-8f0a-c2bf900dead8@github.com>

On Fri, 5 Aug 2022 09:02:44 GMT, ScientificWare <duke at openjdk.org> wrote:

>> Hello @scientificware, what you propose here, I think looks fine. Additionally can you also update the copyright years on this file from `Copyright (c) 1998, 2020,` to `Copyright (c) 1998, 2022,`?
>> 
>> I see that the changed file resides at `make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java` and I think this needs to be reviewed by the build team. @magicus, is it OK if I re-add the `build` label for this PR?
>
> Hello @jaikiran, the copyright years were updated by a previous commit.

@scientificware, please issue the integrate command when you are ready and I can sponsor this for you. In the meantime, I'll run some tests to be sure that this change is fine.

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

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

From alanb at openjdk.org  Tue Aug  9 05:53:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 05:53:22 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
 <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>
Message-ID: <BX_UHsETk2nbNMcvFM0y2_sP90IRCfUZtSj-0SoJw40=.b0719da1-dedf-4273-bd61-838b643d1b1b@github.com>

On Mon, 8 Aug 2022 22:34:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I would also suggest that the join() sentence simply be the last sentence of the above paragraph:
>> 
>>> The join method can be be used to wait for a thread to terminate.
>
> The whole paragraph is about thread termination, so I don't think we need to say "terminate" again in the last sentence. We could mention isAlive or the TERMINATED state, but that brings in Thread.State which which require a discussion of the thread's life cycle.
> 
> The "join" sentence was kind of tacked on to the end of a paragraph in the original text; Alex suggested that I separate it into its own paragraph when we were working on the "termination" paragraph. Alex doesn't mind single-sentence paragraphs, which isn't my preference. But tacking the "join" sentence onto the end of the "termination" paragraph actually doesn't make any sense. Termination is something that happens to _this_ thread. The join method is called from _another_ thread, and this implicit shift of viewpoint would weaken the paragraph.
> 
> Frankly I think there needs to be a separate editorial pass over the Thread docs. I know they were just rewritten in JDK 19, but there are some odd things about it. The Thread.State life cycle isn't explained and isn't referenced by methods such as start() and isAlive(). Also, various mentions of uncaught exception handling talk about a thread's abrupt termination. There isn't any such thing; a _method_ can complete normally or abruptly, and when a thread's run() method completes either way, the thread simply terminates.

Thread.State was added (in Java 5) for monitoring and management purposes, it's not an API that most libraries or programs would use. It could be introduced in the class description and referenced from other APIs that change/test the state but it would encourage use beyond the original intent.

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

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

From plevart at openjdk.org  Tue Aug  9 06:53:28 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 9 Aug 2022 06:53:28 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v15]
In-Reply-To: <5_6Tfzs75GqnzF4jscfhvvILa0JGNBfjMCAOfXn6VP8=.6393d760-fe4a-4080-ade0-3139e3123af5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <gC_jRzeU35COe5DyhJE1liqmekHZYlnjhVLVTzpIKMc=.3eb12ab7-7246-4b7d-b790-c01b560b0d9b@github.com>
 <5_6Tfzs75GqnzF4jscfhvvILa0JGNBfjMCAOfXn6VP8=.6393d760-fe4a-4080-ade0-3139e3123af5@github.com>
Message-ID: <DA3m22wW8VHGFHTFUIzcqlCI3mAfg4c9N9_JnSNynwU=.dcb19a2e-b33e-44bc-abbe-67d1f43e5de2@github.com>

On Sun, 10 Jul 2022 10:20:31 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>>   
>>   * Added JMH
>
> Here are JMH test results on my stable perf laptop (cpu fixed: 4 real cpu cores at 2ghz, HT disabled, i7 6820k):
> https://github.com/bourgesl/bourgesl.github.io/blob/master/bench-220709-summary-2.log
> 
> It confirms Vladimir results: 50% gain in average in parallelSort(), huge gains (x5) on large random arrays...
> 
> As DPQS relies on ForkJoinPool.getCommonParallelism = 3 on my machine, MT speedup is only x3 ! 
> I observed max 300%/400% cpu load when parallelSort() runs on large arrays...
> Why does it return NCpuCore - 1 ?

Hi @bourgesl, 
In order to convince reviewers of the benefits (and lack of drawbacks) of your effort, you could present the results of benchmarks in a friendlier way. Looking at the published JMH code and published results, I can only suspect the results labeled with "new*" are actually obtained by running the "test*" JMH benchmarks with the "patched" JDK and the published "test*" results are obtained by running with "unpatched" JDK? If you want to present the results in a friendlier way, graph them. It's easy. Just publish the unmodified pre and post JMH outputs as two public GISTs and then point to them with this tool: https://jmh.morethan.io/ ...
CPU time / real time is one aspect of performance. Allocation is another. JMH has an option to measure both. Show that your claim about less aggressive memory allocation is true. It would be interesting also to show the effect of a fall-back mechanism when the allocation of buffers is not successful (again in a pre/post fashion).
I can see there is a lot of effort put into this change. It would be a shame that it doesn't gain enough interest just because it requires too much effort to study it.

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

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

From duke at openjdk.org  Tue Aug  9 08:34:18 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 9 Aug 2022 08:34:18 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2]
In-Reply-To: <DVnDiU08bGVW5rNORbGY2dI0d8L5MEzn7SNNwmv-syw=.2b488214-1f6f-4897-8f0a-c2bf900dead8@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <hLOXzlNDgOIpnD25Z0OSHU1ZJItI0X6PhDVsQn1ygCM=.086652ca-efbd-494c-85d9-0321abf53938@github.com>
 <R7twWCuRjFVVtaQNmDkGipOO9ShNEZXjYiz8bO5Gzc4=.9fe6b60f-5232-4572-ae1a-28b701bc1fc7@github.com>
 <daorXu_NRyh6_DWKilgiwi3BJTB-vYOFcu7jhEpjRxg=.22750241-e53d-410b-9c83-4051b16ce644@github.com>
 <uChH4TsDs7SA5xbTBSfrzP4Rlk7ghHiKAOzSJ15jzgY=.d30e91a0-df94-45a0-baa8-9a7c548ca213@github.com>
 <DVnDiU08bGVW5rNORbGY2dI0d8L5MEzn7SNNwmv-syw=.2b488214-1f6f-4897-8f0a-c2bf900dead8@github.com>
Message-ID: <v5Vc-B0-PIsje2br15eKyw6NyNfm184xUx6Dr6d2-4M=.1bec513b-b393-4e6f-84d7-a46628e75125@github.com>

On Tue, 9 Aug 2022 02:37:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @jaikiran, the copyright years were updated by a previous commit.
>
> @scientificware, please issue the integrate command when you are ready and I can sponsor this for you. In the meantime, I'll run some tests to be sure that this change is fine.

@jaikiran, Done and thanks for your sponsoring and reviewing.

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

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

From jpai at openjdk.org  Tue Aug  9 08:43:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 08:43:44 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
Message-ID: <DwxVztfTOWRNiPVu7Qoc_dyNYIbzUbk5mCWyoEwhT5I=.2540f18e-2450-4e17-b5a2-ec258a666698@github.com>

On Fri, 5 Aug 2022 08:59:00 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is tracked in JBS as
>> 
>> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
>> 
>> Unused imports in DTDBuider.java.
>> 
>>> **Remove unused imports from DTDBuilder.java**
>> 
>> Some imports are no more used.
>> 
>> - java.io.FileNotFoundException;
>> - java.io.BufferedInputStream;
>> - java.io.OutputStream;
>> - java.util.BitSet;
>> - java.util.StringTokenizer;
>> - java.util.Properties;
>> - java.util.zip.DeflaterOutputStream;
>> - java.util.zip.Deflater;
>> - java.net.URL;
>> 
>> https://github.com/scientificware/jdk/issues/4
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>  - Remove unused imports.
>    
>    Some imports are no more used.
>    
>    - java.io.FileNotFoundException;
>    - java.io.BufferedInputStream;
>    - java.io.OutputStream;
>    - java.util.BitSet;
>    - java.util.StringTokenizer;
>    - java.util.Properties;
>    - java.util.zip.DeflaterOutputStream;
>    - java.util.zip.Deflater;
>    - java.net.URL;

The tests came back fine without any issue.

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

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

From duke at openjdk.org  Tue Aug  9 08:43:44 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 9 Aug 2022 08:43:44 GMT
Subject: Integrated: JDK-8289741 : Remove unused imports from DTDBuilder.java
In-Reply-To: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
Message-ID: <MP8P0IqqjzN2yRhjoKtPcyTsP6yL_xw0bXk4E8ar2FY=.9a9039ba-a0cc-433a-a01f-6902021e6816@github.com>

On Mon, 4 Jul 2022 07:04:40 GMT, ScientificWare <duke at openjdk.org> wrote:

> This is tracked in JBS as
> 
> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) and duplicated by [JDK-8290070](https://bugs.openjdk.org/browse/JDK-8290070)
> 
> Unused imports in DTDBuider.java.
> 
>> **Remove unused imports from DTDBuilder.java**
> 
> Some imports are no more used.
> 
> - java.io.FileNotFoundException;
> - java.io.BufferedInputStream;
> - java.io.OutputStream;
> - java.util.BitSet;
> - java.util.StringTokenizer;
> - java.util.Properties;
> - java.util.zip.DeflaterOutputStream;
> - java.util.zip.Deflater;
> - java.net.URL;
> 
> https://github.com/scientificware/jdk/issues/4

This pull request has now been integrated.

Changeset: 2712bc3f
Author:    ScientificWare <info at scientificware.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2712bc3f79990f27fe9a624a7a818ba1c2c74b67
Stats:     11 lines in 1 file changed: 0 ins; 10 del; 1 mod

8289741: Remove unused imports from DTDBuilder.java

Reviewed-by: jpai

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

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

From duke at openjdk.org  Tue Aug  9 08:54:17 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 9 Aug 2022 08:54:17 GMT
Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v3]
In-Reply-To: <DwxVztfTOWRNiPVu7Qoc_dyNYIbzUbk5mCWyoEwhT5I=.2540f18e-2450-4e17-b5a2-ec258a666698@github.com>
References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com>
 <jEaNCC9T0V9BXT0zeXyu6HorqvBokPa87sABsjHVWlg=.20adeffb-5eb0-459d-948b-e8695b4fb63e@github.com>
 <DwxVztfTOWRNiPVu7Qoc_dyNYIbzUbk5mCWyoEwhT5I=.2540f18e-2450-4e17-b5a2-ec258a666698@github.com>
Message-ID: <X1DtCJ7suL99C-F_FXlNN0vLzwhvoFvKytOpez-tcoE=.84e8f74d-fcce-426e-a7f2-17acd1871968@github.com>

On Tue, 9 Aug 2022 08:38:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder
>>  - Remove unused imports.
>>    
>>    Some imports are no more used.
>>    
>>    - java.io.FileNotFoundException;
>>    - java.io.BufferedInputStream;
>>    - java.io.OutputStream;
>>    - java.util.BitSet;
>>    - java.util.StringTokenizer;
>>    - java.util.Properties;
>>    - java.util.zip.DeflaterOutputStream;
>>    - java.util.zip.Deflater;
>>    - java.net.URL;
>
> The tests came back fine without any issue.

@jaikiran Greats Thanks.

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

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

From jpai at openjdk.org  Tue Aug  9 09:34:33 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 09:34:33 GMT
Subject: Withdrawn: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <iM_cgDuT2A39hw5d4TLJLBmQqFfodoQJ9tAG2JW72Mk=.d7b398be-357a-42bb-b267-21caa2f8343b@github.com>

On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Aug  9 09:44:59 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 09:44:59 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
Message-ID: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>

(This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)

Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

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

Commit messages:
 - incorporate review comments from Stuart
 - Merge latest from master branch
 - add newline at the end of the new file
 - Add tests for the new HashSet#newHashSet and LinkedHashSet#newLinkedHashSet APIs
 - add a check for negative numElements very early in the new APIs of HashSet and LinkedHashSet
 - 8285405: add test and check for negative argument to HashMap::newHashMap et al

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

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

From jpai at openjdk.org  Tue Aug  9 09:44:59 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Aug 2022 09:44:59 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <7-8JUFOvjbNh9QDnML8KV_wVPGl3h-2ZNoOo5Tngo1I=.39175ea3-f1d7-4050-9f00-7ca0f093f6b4@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

Hello Stuart (@stuart-marks), as suggested by you in the pull request that you previously reviewed, I've now moved the tests to `HashMap/WhiteBoxResizeTest` and it now tests the new APIs using (only) `-1` as the negative input.

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

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

From chegar at openjdk.org  Tue Aug  9 10:10:57 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 9 Aug 2022 10:10:57 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <SRMua1FkzWQ4J4azLmf4KhqYw5ERRqsAsiIvRpEHA9s=.ba657ea9-5c16-449a-bdf5-3f000f6d7ffe@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

LGTM

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

Marked as reviewed by chegar (Reviewer).

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

From jlahoda at openjdk.org  Tue Aug  9 10:31:01 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Aug 2022 10:31:01 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <AGsGA4cV1qR_aYJTJmk-slqLbqXX2eODg2vBSQ5gzBk=.31327773-2535-4ddc-99bc-1347a476ded2@github.com>

On Fri, 5 Aug 2022 16:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
> 
> switch (obj) {
>     case String s when s.isEmpty() -> {}
>     case String s -> {}
>     case CharSequence cs -> {}
>     ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
> 
> obj == null ? -1
>                   : switch (restartIndex) {
>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                         ...
>                         default -> <labels-count>;
>                     }
> 
> 
> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
> 
> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
> 
> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
> 
> 
> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

> Would it be possible to add a special case where the labels are all the same type? Like all labels are Class.class or Object.class? While testing out the pattern matching, I've found myself doing the following
> 
> ```java
> switch (o) {
>     case Class<?> c when c == Object.class -> {}
>     case Class<?> c when c == Integer.class -> {}
>     case Class<?> c when c == String.class -> {}
>     case Class<?> c when c == Double.class -> {}
>     // ...
> }
> ```

I think that there may eventually be some improvements, although the current round of patches is not intended to improve this pattern, sorry. Also, I would not expect better behavior that a sequence of ifs.

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

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

From duke at openjdk.org  Tue Aug  9 11:01:21 2022
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 9 Aug 2022 11:01:21 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <AGsGA4cV1qR_aYJTJmk-slqLbqXX2eODg2vBSQ5gzBk=.31327773-2535-4ddc-99bc-1347a476ded2@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <AGsGA4cV1qR_aYJTJmk-slqLbqXX2eODg2vBSQ5gzBk=.31327773-2535-4ddc-99bc-1347a476ded2@github.com>
Message-ID: <_3jDdAYLjgnOVQNZfI_5FN4pVpL0BlkIK3Zz4fp5pRk=.5c3fe8c2-ad33-4722-b87d-7ade476daa3d@github.com>

On Tue, 9 Aug 2022 10:28:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > Would it be possible to add a special case where the labels are all the same type? Like all labels are Class.class or Object.class? While testing out the pattern matching, I've found myself doing the following
> > ```java
> > switch (o) {
> >     case Class<?> c when c == Object.class -> {}
> >     case Class<?> c when c == Integer.class -> {}
> >     case Class<?> c when c == String.class -> {}
> >     case Class<?> c when c == Double.class -> {}
> >     // ...
> > }
> > ```
> 
> I think that there may eventually be some improvements, although the current round of patches is not intended to improve this pattern, sorry. Also, I would not expect better behavior that a sequence of ifs.

If it eventually gets the same speed as a sequence of ifs, it would be great for me. Right now it is much slower. However, do you think it would be good to track this pattern or should the javac simplify the code generation to not use `SwitchBootstrap.typeSwitch` in this case?

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

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

From alanb at openjdk.org  Tue Aug  9 13:59:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 13:59:26 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v5]
In-Reply-To: <ezYz_s8SKOP0suG8aGtlLuRMftXnNp0vY8K0BKZ6FJc=.96f6c33f-79a4-4d28-94e0-74c8b36f9871@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <ezYz_s8SKOP0suG8aGtlLuRMftXnNp0vY8K0BKZ6FJc=.96f6c33f-79a4-4d28-94e0-74c8b36f9871@github.com>
Message-ID: <zbFn4d51vWx1FAMCYdO-wG3MDVXfVg41edzoFvy7fwc=.4acffd6f-58cb-417a-96bf-9c5e3496d75b@github.com>

On Mon, 8 Aug 2022 22:59:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Initial edits to addShutdownHook from Alex.
>> 
>> See [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036).
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates from Alan, David, and Alex.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Tue Aug  9 13:59:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 13:59:27 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <BX_UHsETk2nbNMcvFM0y2_sP90IRCfUZtSj-0SoJw40=.b0719da1-dedf-4273-bd61-838b643d1b1b@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
 <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>
 <BX_UHsETk2nbNMcvFM0y2_sP90IRCfUZtSj-0SoJw40=.b0719da1-dedf-4273-bd61-838b643d1b1b@github.com>
Message-ID: <FM7sQqMq6aYLngEIKR3d1rEAB4cr48JvRux0xQvhum0=.d79d145b-2413-4933-9430-a0eb9d5154d2@github.com>

On Tue, 9 Aug 2022 05:51:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The whole paragraph is about thread termination, so I don't think we need to say "terminate" again in the last sentence. We could mention isAlive or the TERMINATED state, but that brings in Thread.State which which require a discussion of the thread's life cycle.
>> 
>> The "join" sentence was kind of tacked on to the end of a paragraph in the original text; Alex suggested that I separate it into its own paragraph when we were working on the "termination" paragraph. Alex doesn't mind single-sentence paragraphs, which isn't my preference. But tacking the "join" sentence onto the end of the "termination" paragraph actually doesn't make any sense. Termination is something that happens to _this_ thread. The join method is called from _another_ thread, and this implicit shift of viewpoint would weaken the paragraph.
>> 
>> Frankly I think there needs to be a separate editorial pass over the Thread docs. I know they were just rewritten in JDK 19, but there are some odd things about it. The Thread.State life cycle isn't explained and isn't referenced by methods such as start() and isAlive(). Also, various mentions of uncaught exception handling talk about a thread's abrupt termination. There isn't any such thing; a _method_ can complete normally or abruptly, and when a thread's run() method completes either way, the thread simply terminates.
>
> Thread.State was added (in Java 5) for monitoring and management purposes, it's not an API that most libraries or programs would use. It could be introduced in the class description and referenced from other APIs that change/test the state but it would encourage use beyond the original intent.

What you have is okay although I would have preferred if the sentence on the join method was in the previous paragraph rather as it fits with termination.

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

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

From naoto at openjdk.org  Tue Aug  9 17:06:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Aug 2022 17:06:30 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <pjuHecMsJ3CnVZSutKBtjh-TpajM6IqWJqi7rOP7Ydg=.f6498dcf-b3e0-486a-b3c5-192980118090@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

Looks good as it stands.

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 458:

> 456:             // received the expected exception
> 457:         }
> 458:     }

Could utilize `assertThrows`, instead of try-catch.

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

Marked as reviewed by naoto (Reviewer).

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

From bpb at openjdk.org  Tue Aug  9 17:09:37 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 17:09:37 GMT
Subject: Integrated: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <jscnD5JoiY33aPu7Zw6xgKE6ZcCyD8g1EQdWo1vLW48=.881f0109-7a92-4500-85f6-77122b6a04f7@github.com>

On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

This pull request has now been integrated.

Changeset: 4040927d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4040927d1750dd00611cc6465507dd0bc694a18f
Stats:     52 lines in 8 files changed: 37 ins; 0 del; 15 mod

8290047: (fs) FileSystem.getPathMatcher does not check for ":" at last index

Reviewed-by: naoto, rriggs, alanb, lancea

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

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

From asemenyuk at openjdk.org  Tue Aug  9 17:53:36 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 9 Aug 2022 17:53:36 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <k6yuO7WWfo6sUSzqiUmIpuktBZjIi1IlHrmDkULvDvY=.bd053666-f50f-4777-9377-0df00efd5fa5@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good. Approved that part.

-------------

PR: https://git.openjdk.org/jdk19/pull/154

From lancea at openjdk.org  Tue Aug  9 18:09:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 9 Aug 2022 18:09:02 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <M4juIpEwjoWIhKP4Ra_rUjzsczrHGuFs1UmH9zXFqpo=.03483adb-fd74-421f-9c1c-eadd5846e2b5@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

Changes requested by lancea (Reviewer).

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 452:

> 450:         try {
> 451:             method.apply(-1);
> 452:             // expected to fail but didn't

You could use `assert.throws(IllegalArgumenException.class, () -> method.apply(-1));`. which would be a bit cleaner IMHO

-------------

PR: https://git.openjdk.org/jdk/pull/9806

From duke at openjdk.org  Tue Aug  9 18:29:56 2022
From: duke at openjdk.org (Bill Huang)
Date: Tue, 9 Aug 2022 18:29:56 GMT
Subject: Integrated: JDK-8290836 Improve test coverage for XPath functions:
 String Functions
In-Reply-To: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
References: <8r-LFPbiQ73pvAbxwbnwOHHT-y_IBUCbacAzMzgrw48=.4bac3cd8-19c7-41ba-8178-d227c83ab935@github.com>
Message-ID: <wtFvOkkDCQ_9wh3EC52HdMevXZjQkSgZTZH5LaTGeqA=.81292b3f-896b-4c58-a527-0f859cea97cc@github.com>

On Thu, 4 Aug 2022 17:40:43 GMT, Bill Huang <duke at openjdk.org> wrote:

> Improve test coverage for XPath functions: [JDK-8290836](https://bugs.openjdk.org/browse/JDK-8290836), [JDK-8290837](https://bugs.openjdk.org/browse/JDK-8290837), [JDK-8290838](https://bugs.openjdk.org/browse/JDK-8290838).

This pull request has now been integrated.

Changeset: d889264c
Author:    Bill Huang <bill.w.huang at oracle.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d889264c6123b6c28bdd6336f5ae547e4e441aa7
Stats:     821 lines in 5 files changed: 806 ins; 3 del; 12 mod

8290836: Improve test coverage for XPath functions: String Functions
8290837: Improve test coverage for XPath functions: Boolean Functions
8290838: Improve test coverage for XPath functions: Number Functions

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/9752

From mchung at openjdk.org  Tue Aug  9 18:39:03 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Aug 2022 18:39:03 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
Message-ID: <nVFMGtUIg35jvpAzjTicrnj_hbgd_YlIo5TOMZl6dwA=.645681a6-9404-4670-bd81-228dff4b09e1@github.com>

On Sat, 6 Aug 2022 14:55:17 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>    
>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Inline max Integer.stringSize
>  - Estimate length
>  - Address comments
>  - Precompute StackTraceElement toString length
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Optimize StackTraceElement.toString()
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f9948294...c9ae3897

Looks good to me.  Minor suggestions.

src/java.base/share/classes/java/lang/StackTraceElement.java line 359:

> 357:     @Override
> 358:     public String toString() {
> 359:         int estimatedLength = Objects.requireNonNullElse(classLoaderName, "").length() + 1

Nit: suggest to refactor this and define a private static `length(String s)` method.

src/java.base/share/classes/java/lang/StackTraceElement.java line 364:

> 362:                 + declaringClass.length() + 1
> 363:                 + methodName.length() + 1
> 364:                 + Math.max("Unknown Source".length(), Objects.requireNonNullElse(fileName, "").length()) + 1

I suggest to define a static variable = "Unknown Source" be used here and line 387.   Same for "Native Method" which can also be accounted for.

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From duke at openjdk.org  Tue Aug  9 18:55:04 2022
From: duke at openjdk.org (Max Mielchen)
Date: Tue, 9 Aug 2022 18:55:04 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
Message-ID: <IE-K_ZRPE99kNWOfkOiF0esnRgz6jmhgwv2GzFdK4V8=.5168a5e5-bf6d-4566-9b71-3f5de7876329@github.com>

On Sat, 6 Aug 2022 14:55:17 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>    
>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
>  - Mark StackTraceElement SerialTest for bug 8291641
>  - Inline max Integer.stringSize
>  - Estimate length
>  - Address comments
>  - Precompute StackTraceElement toString length
>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>  - Optimize StackTraceElement.toString()
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f5c5e107...c9ae3897

src/java.base/share/classes/java/lang/StackTraceElement.java line 357:

> 355:      * @see    Throwable#printStackTrace()
> 356:      */
> 357:     @Override

The override makes no difference.

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From dcubed at openjdk.org  Tue Aug  9 19:24:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 19:24:49 GMT
Subject: RFR: 8292132: ProblemList
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
In-Reply-To: <0GBPa3dcpske3yo761AZOcIMIxvfVb6SJ0ZMVa7NdF4=.06e16fc8-1e5d-44d8-8c69-347d5d881685@github.com>
References: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>
 <0GBPa3dcpske3yo761AZOcIMIxvfVb6SJ0ZMVa7NdF4=.06e16fc8-1e5d-44d8-8c69-347d5d881685@github.com>
Message-ID: <Qrulfn4hmoNvVWvok2WiPdveTwdriok_gk9T__OnMGU=.26249319-e8ef-48cb-89e4-ca9c1f06a026@github.com>

On Tue, 9 Aug 2022 19:19:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the fast review!

-------------

PR: https://git.openjdk.org/jdk/pull/9812

From dcubed at openjdk.org  Tue Aug  9 19:24:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 19:24:48 GMT
Subject: RFR: 8292132: ProblemList
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
Message-ID: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>

A trivial fix to ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java.

-------------

Commit messages:
 - 8292132: ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java

Changes: https://git.openjdk.org/jdk/pull/9812/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9812&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292132
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9812.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9812/head:pull/9812

PR: https://git.openjdk.org/jdk/pull/9812

From bpb at openjdk.org  Tue Aug  9 19:24:48 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 19:24:48 GMT
Subject: RFR: 8292132: ProblemList
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
In-Reply-To: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>
References: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>
Message-ID: <0GBPa3dcpske3yo761AZOcIMIxvfVb6SJ0ZMVa7NdF4=.06e16fc8-1e5d-44d8-8c69-347d5d881685@github.com>

On Tue, 9 Aug 2022 19:16:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9812

From dcubed at openjdk.org  Tue Aug  9 19:30:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 19:30:53 GMT
Subject: Integrated: 8292132: ProblemList
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
In-Reply-To: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>
References: <_Yw1VDkmYgMF_mONqqc9AyAv7TdsGnEJMs9PMQYlcc4=.c21fc8ba-90d6-4f53-b56c-a6e364904b61@github.com>
Message-ID: <YIipPjcGjdM4TLfAZtAJ-vuq5yOMBPwGAzOgdDbFRdU=.1fe6d013-976d-4830-b886-d6b23c856ae4@github.com>

On Tue, 9 Aug 2022 19:16:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java.

This pull request has now been integrated.

Changeset: 57e0da15
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57e0da1578b78f7ac83e9621554d0e81dfa2af67
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8292132: ProblemList jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/9812

From duke at openjdk.org  Tue Aug  9 20:26:43 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 9 Aug 2022 20:26:43 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v8]
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <quOLzexBGMfuQWsg8NdDxZ1ltQhyrPKMESk0uZgF_tU=.781df74c-4f62-451b-b3b7-b9d31749b6cf@github.com>

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:

  Extract constants, define & use `int length(@Nullable String s)`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9665/files
  - new: https://git.openjdk.org/jdk/pull/9665/files/c9ae3897..5bdc66f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9665&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9665&range=06-07

  Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9665.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9665/head:pull/9665

PR: https://git.openjdk.org/jdk/pull/9665

From duke at openjdk.org  Tue Aug  9 20:26:49 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 9 Aug 2022 20:26:49 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <nVFMGtUIg35jvpAzjTicrnj_hbgd_YlIo5TOMZl6dwA=.645681a6-9404-4670-bd81-228dff4b09e1@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
 <nVFMGtUIg35jvpAzjTicrnj_hbgd_YlIo5TOMZl6dwA=.645681a6-9404-4670-bd81-228dff4b09e1@github.com>
Message-ID: <PkgLGXrMZZ48XaAO809f-SuqvFPS3IWaBaBlMPMmH9M=.1c6fd39d-15c2-403b-9a64-dc4d53a1c518@github.com>

On Tue, 9 Aug 2022 18:35:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David Schlosnagle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>>  - Mark StackTraceElement SerialTest for bug 8291641
>>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>>    
>>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
>>  - Mark StackTraceElement SerialTest for bug 8291641
>>  - Inline max Integer.stringSize
>>  - Estimate length
>>  - Address comments
>>  - Precompute StackTraceElement toString length
>>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>>  - Optimize StackTraceElement.toString()
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/de2d083f...c9ae3897
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 359:
> 
>> 357:     @Override
>> 358:     public String toString() {
>> 359:         int estimatedLength = Objects.requireNonNullElse(classLoaderName, "").length() + 1
> 
> Nit: suggest to refactor this and define a private static `length(String s)` method.

updated

> src/java.base/share/classes/java/lang/StackTraceElement.java line 364:
> 
>> 362:                 + declaringClass.length() + 1
>> 363:                 + methodName.length() + 1
>> 364:                 + Math.max("Unknown Source".length(), Objects.requireNonNullElse(fileName, "").length()) + 1
> 
> I suggest to define a static variable = "Unknown Source" be used here and line 387.   Same for "Native Method" which can also be accounted for.

pulled out to private static final fields

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From duke at openjdk.org  Tue Aug  9 20:29:33 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 9 Aug 2022 20:29:33 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v7]
In-Reply-To: <IE-K_ZRPE99kNWOfkOiF0esnRgz6jmhgwv2GzFdK4V8=.5168a5e5-bf6d-4566-9b71-3f5de7876329@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <2uWmIhGS5CCj_mmEGlZt382Wmpgk0nZMQ2mIFQ30rzE=.6f9c9802-27de-4f45-a0ea-d812323220fb@github.com>
 <IE-K_ZRPE99kNWOfkOiF0esnRgz6jmhgwv2GzFdK4V8=.5168a5e5-bf6d-4566-9b71-3f5de7876329@github.com>
Message-ID: <82s79LGixymkl61x2r0xSHt4ZKnR-k5pTHtlaAY4VK8=.762ebf2f-bc39-49f8-9ca0-642704300f82@github.com>

On Mon, 8 Aug 2022 18:55:39 GMT, Max Mielchen <duke at openjdk.org> wrote:

>> David Schlosnagle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>>  - Mark StackTraceElement SerialTest for bug 8291641
>>  - Revert "Mark StackTraceElement SerialTest for bug 8291641"
>>    
>>    This reverts commit e7b04faafb026e61829c81c75121e2d3be6644d9.
>>  - Mark StackTraceElement SerialTest for bug 8291641
>>  - Inline max Integer.stringSize
>>  - Estimate length
>>  - Address comments
>>  - Precompute StackTraceElement toString length
>>  - Merge remote-tracking branch 'origin/master' into ds/StackTraceElement
>>  - Optimize StackTraceElement.toString()
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/2addb249...c9ae3897
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 357:
> 
>> 355:      * @see    Throwable#printStackTrace()
>> 356:      */
>> 357:     @Override
> 
> The override makes no difference.

ack. I can remove if necessary, but [stylistically prefer to mark overridden methods as such](https://google.github.io/styleguide/javaguide.html#s6.1-override-annotation) (and automatically enforce via [static analysis](https://errorprone.info/bugpattern/MissingOverride) )

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From naoto at openjdk.org  Tue Aug  9 20:40:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Aug 2022 20:40:40 GMT
Subject: RFR: 8291916: Unexpected output on Arabic Windows command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

I looked at this issue a bit more. It looks to me that the issue is caused by the fact that the encoding of `System.out` falls back to the default encoding, as `IBM864` is not in `java.base`. This issue seems not new and reproducible with the releases since JDK9 where modularization has been introduced. Also, I think other encodings than those `IBM*` listed here, can possibly cause this issue. In order to fix this completely, those obscure encodings also have to be in `java.base` which I don't think we would want to do.

-------------

PR: https://git.openjdk.org/jdk/pull/9761

From duke at openjdk.org  Tue Aug  9 21:23:04 2022
From: duke at openjdk.org (Bill Huang)
Date: Tue, 9 Aug 2022 21:23:04 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests
 to java version
Message-ID: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>

This task converts 5 shell tests below to java version. 
test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
test/java/lang/management/MemoryMXBean/PendingAllGC.sh

-------------

Commit messages:
 - Removed othervm option in Pending.java.
 - Converted MemoryMXBean shell tests to java version.

Changes: https://git.openjdk.org/jdk/pull/9813/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292064
  Stats: 356 lines in 9 files changed: 48 ins; 303 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9813.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813

PR: https://git.openjdk.org/jdk/pull/9813

From lmesnik at openjdk.org  Tue Aug  9 22:30:32 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Aug 2022 22:30:32 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <t55pQRbvhOdoVQJwhw2ZE0-leDp1t-JleRoloUUM3lk=.77547312-50b5-4e83-aca3-ab0a81682bc6@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> wrote:

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

Isn't it a good time to remove all GC settings and allow user to set GC? Also, remove or update 'requires' if any of GC are not supported,

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From achung at openjdk.org  Tue Aug  9 22:30:54 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 9 Aug 2022 22:30:54 GMT
Subject: [jdk19] Integrated: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <q3eKnCK-mTAP42I8K9ifRoP0RBS0nLNwsGoZpEt_e0A=.5da69e5f-4232-40e4-8f69-ccae924fcd3a@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

This pull request has now been integrated.

Changeset: 0def5316
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/0def5316cd2ec7699c649bf67bf58e6315c3010b
Stats:     684 lines in 42 files changed: 87 ins; 540 del; 57 mod

8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

Reviewed-by: naoto, asemenyuk

-------------

PR: https://git.openjdk.org/jdk19/pull/154

From duke at openjdk.org  Wed Aug 10 01:12:38 2022
From: duke at openjdk.org (duke)
Date: Wed, 10 Aug 2022 01:12:38 GMT
Subject: Withdrawn: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <JzPqCnxWrOncaV5qoixpfEbL7G37PFiYRJ7tGOrf5j0=.9eb20151-1e81-4feb-91c1-fc9c415177ed@github.com>

On Fri, 4 Mar 2022 15:54:14 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/7700

From darcy at openjdk.org  Wed Aug 10 01:54:56 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Aug 2022 01:54:56 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v6]
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <eYpXsqNpaDptZS3iMPH7xoyxWWimkkV7SU7mUNdtwuI=.baf726b6-6aab-47a3-b194-cc2fd303985f@github.com>

> JDK-8289106: Add model of class file versions to core reflection

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 18 additional commits since the last revision:

 - Implement code review feedback.
 - Update ClassFileVersionTest.java.
 - Merge branch 'master' into JDK-8289106
 - Appease jcheck.
 - Finish more precise versioned location support; udpate tests.
 - Partial implementation of version-depdendent locations() with tests.
 - Merge branch 'master' into JDK-8289106
 - Merge branch 'master' into JDK-8289106
 - Add method to map from major class file version.
 - Merge branch 'master' into JDK-8289106
 - ... and 8 more: https://git.openjdk.org/jdk/compare/aedfcb9d...2e6dfc8e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9299/files
  - new: https://git.openjdk.org/jdk/pull/9299/files/34aa4f42..2e6dfc8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=04-05

  Stats: 14248 lines in 687 files changed: 8784 ins; 3529 del; 1935 mod
  Patch: https://git.openjdk.org/jdk/pull/9299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299

PR: https://git.openjdk.org/jdk/pull/9299

From darcy at openjdk.org  Wed Aug 10 01:54:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Aug 2022 01:54:57 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v5]
In-Reply-To: <Ot3HRJDhF-keVAAjm76cUO9s9DSZzs_kbm0ZggvdcmE=.4e791963-a81d-4b70-8216-9f649114032a@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <xQy_kU-pUnRZtwQSM59ugpXpPmP5HombPvBpxl_SpeQ=.6cc5b317-3a8f-41c2-9def-8686ee37a9cf@github.com>
 <zpAzGcYm_sgQ4HG59Yymo78OQyMzCQ856R2j07SQ0QE=.fbfa6b72-2c1a-42e2-846c-f21fc861bfed@github.com>
 <tUX-ZrLZol14PoteIR8om0IyuwCi7ZrjBJenooAA-8A=.dc29430a-5a8b-4b09-91e6-990b5d4d33da@github.com>
 <tbhhHvHT62PIqglDmGIg2RyA6Kq8wl7-p1CqF9qGq2Q=.91e062b9-1887-4184-8967-35b2d0d61773@github.com>
 <Ot3HRJDhF-keVAAjm76cUO9s9DSZzs_kbm0ZggvdcmE=.4e791963-a81d-4b70-8216-9f649114032a@github.com>
Message-ID: <Smo56fLnts8duaywnzQj1M5BZgo5rK1f4oM0JrBhCFI=.43a08e10-bc4a-41b2-a79a-613f75330a61@github.com>

On Tue, 2 Aug 2022 21:21:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> True, many ways to factor the code. Another possibility is add a field to the enum that holds a `java.util.Function<Iteger, Set<Location>>)` and initialize it each with a lambda of the code now in the locations(cffv) method that maps the cffv to the set of locations.

Pushed a refactoring to use lambdas; thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From duke at openjdk.org  Wed Aug 10 02:10:25 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 10 Aug 2022 02:10:25 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v10]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <x2l5NJ4dB6yRfSGryPbHf_LW3Q2G6jvwysxE2Gr1f8s=.36811dd0-a7a8-46d2-bf2e-59fc6ebd856e@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  add bean to list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/2c149c10..fa6fed19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=08-09

  Stats: 210 lines in 4 files changed: 120 ins; 86 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372

PR: https://git.openjdk.org/jdk/pull/9372

From jpai at openjdk.org  Wed Aug 10 02:54:37 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Aug 2022 02:54:37 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v2]
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Review comment - use assertThrows()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9806/files
  - new: https://git.openjdk.org/jdk/pull/9806/files/ee516ffd..e61cb275

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9806&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9806&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9806.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9806/head:pull/9806

PR: https://git.openjdk.org/jdk/pull/9806

From jpai at openjdk.org  Wed Aug 10 02:54:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Aug 2022 02:54:38 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <oUs4YfNS4m2gOhaOALTY4ERFN1hyP8dlH4YkVh9oUwA=.01d6e1ae-3f73-4745-a264-261e8072f1a9@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

Thank you Chris, Lance and Naoto for the reviews.

I've now updated the PR to use `assertThrows` as suggested by Naoto and Lance. Test continues to pass.

-------------

PR: https://git.openjdk.org/jdk/pull/9806

From plevart at openjdk.org  Wed Aug 10 06:56:39 2022
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 10 Aug 2022 06:56:39 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <v_OWfLAWNiNej5iXxbd6EAipBgBX21Zx8XyiWu7HEas=.6c5119a3-ac72-4ae7-b96a-503715e3b842@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <v_OWfLAWNiNej5iXxbd6EAipBgBX21Zx8XyiWu7HEas=.6c5119a3-ac72-4ae7-b96a-503715e3b842@github.com>
Message-ID: <0sCoMJnKjMuDqah38a0n-pa_PxfpQfusjc19UmJGR80=.b8f729c8-f8e6-4bb1-8cb7-b59cc1b3e3aa@github.com>

On Sun, 7 Aug 2022 08:14:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Sorry for joining late. I noticed that modsHashCode is a private method and it takes Iterable as a parameter. But everywhere it is called, a Set is passed to it. So why not just calling the set.hashCode() and be done with it? It may be even more optimal in some cases.
> 
> There's a lot going on here as the hash code is generated at link time and we also want it to be reproducible across builds. We also had a CDS bug with the the way that Enum objects were archived - Ioi has fixed that in JDK 19 so we have one less thing to be concerned about now.

Ah, I see. Enum.hashCode() is identity hash code. I have been beaten by that in the past and apparently this is a sore point for many. I wonder if it could be changed. Is unstable hashCode (accross JVM instances) a feature here or just unfortunate implementation detail?

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From lbourges at openjdk.org  Wed Aug 10 09:17:43 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 10 Aug 2022 09:17:43 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v15]
In-Reply-To: <DA3m22wW8VHGFHTFUIzcqlCI3mAfg4c9N9_JnSNynwU=.dcb19a2e-b33e-44bc-abbe-67d1f43e5de2@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <gC_jRzeU35COe5DyhJE1liqmekHZYlnjhVLVTzpIKMc=.3eb12ab7-7246-4b7d-b790-c01b560b0d9b@github.com>
 <5_6Tfzs75GqnzF4jscfhvvILa0JGNBfjMCAOfXn6VP8=.6393d760-fe4a-4080-ade0-3139e3123af5@github.com>
 <DA3m22wW8VHGFHTFUIzcqlCI3mAfg4c9N9_JnSNynwU=.dcb19a2e-b33e-44bc-abbe-67d1f43e5de2@github.com>
Message-ID: <lM9PeJBGr8EPh_5P4xhBCKdC0B5Qy-xBKPPEcpc5Q_Y=.ee181aaa-c852-4fa7-b96f-4ca846e75b28@github.com>

On Tue, 9 Aug 2022 06:49:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Here are JMH test results on my stable perf laptop (cpu fixed: 4 real cpu cores at 2ghz, HT disabled, i7 6820k):
>> https://github.com/bourgesl/bourgesl.github.io/blob/master/bench-220709-summary-2.log
>> 
>> It confirms Vladimir results: 50% gain in average in parallelSort(), huge gains (x5) on large random arrays...
>> 
>> As DPQS relies on ForkJoinPool.getCommonParallelism = 3 on my machine, MT speedup is only x3 ! 
>> I observed max 300%/400% cpu load when parallelSort() runs on large arrays...
>> Why does it return NCpuCore - 1 ?
>
> Hi @bourgesl, 
> In order to convince reviewers of the benefits (and lack of drawbacks) of your effort, you could present the results of benchmarks in a friendlier way. Looking at the published JMH code and published results, I can only suspect the results labeled with "new*" are actually obtained by running the "test*" JMH benchmarks with the "patched" JDK and the published "test*" results are obtained by running with "unpatched" JDK? If you want to present the results in a friendlier way, graph them. It's easy. Just publish the unmodified pre and post JMH outputs as two public GISTs and then point to them with this tool: https://jmh.morethan.io/ ...
> CPU time / real time is one aspect of performance. Allocation is another. JMH has an option to measure both. Show that your claim about less aggressive memory allocation is true. It would be interesting also to show the effect of a fall-back mechanism when the allocation of buffers is not successful (again in a pre/post fashion).
> I can see there is a lot of effort put into this change. It would be a shame that it doesn't gain enough interest just because it requires too much effort to study it.

Hi @plevart 
Thanks for your advices, we will run again jmh tests within 1 week using json output, required by jmh analyzer on the latest dpqs patch.

I agree the patched/unpatched labels are better than new/test labels.

I will write a basic test to sort 1million integers that fails before/passes now using low max heap-mem ~ 64m...

Laurent

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From duke at openjdk.org  Wed Aug 10 09:49:49 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 10 Aug 2022 09:49:49 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v3]
In-Reply-To: <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
Message-ID: <6vw-eGZl8hT6imXESlBV7or9tbwh86YIKhTZpDoW_wo=.356bfba0-f395-4351-a777-1334feba35ac@github.com>

On Tue, 14 Jun 2022 19:36:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287908: Make Executable.getAllGenericParameterTypes() safe

Let's wait a bit

-------------

PR: https://git.openjdk.org/jdk/pull/9064

From lancea at openjdk.org  Wed Aug 10 10:06:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Aug 2022 10:06:32 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v2]
In-Reply-To: <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
 <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
Message-ID: <RTVr0dmxuNQ0LoGioYFz_4wuqHOjqF7Gmrxxxv7AplQ=.96bb482d-666d-49f5-8d3d-a53bf78e130e@github.com>

On Wed, 10 Aug 2022 02:54:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
>> 
>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - use assertThrows()

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9806

From akasko at openjdk.org  Wed Aug 10 13:12:57 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 13:12:57 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:

  fixes for bundling with different cultures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9780/files
  - new: https://git.openjdk.org/jdk/pull/9780/files/097ae46e..a6e6ee1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9780&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9780&range=01-02

  Stats: 52 lines in 7 files changed: 33 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9780/head:pull/9780

PR: https://git.openjdk.org/jdk/pull/9780

From akasko at openjdk.org  Wed Aug 10 13:40:31 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 13:40:31 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <s1joahXAoZ8p00IopSGgCCpNMKZsn75mbAYe4_Br_So=.fff9bd38-a655-4aff-aefc-b586c4dee530@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

Sorry for delay, I've found multiple problems while checking l10n handling manually.

Overview:

1. I've verified, that if an entry is missed in `WinResources_*.properties` file, fallback value from `WinResources.properties` file is actually used. Removed EN entries from non-EN `.properties` files in the patch.

2. I've found a problem in primary `.wxl` file selection, the [logic in code](https://github.com/openjdk/jdk/blob/ecfa38ffa8620e41854a043497f19863da297947/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java#L567) uses `resource.wxl-file-name` to determine the file, but it appeared that all `WinResources_*.properties` files had the same `resource.wxl-file-name=MsiInstallerStrings_en.wxl` entry. I assumed this was an oversight and changed these entries to corresponding localized ones in the patch.

3. I've verified, that if an entry is missed in `.wxl` file, there is no fallback and `light.exe` invocation will fail like this:


InstallDirNotEmptyDlg.wxs(44) : error LGHT0102 : The localization variable !(loc.message.install.dir.exist) is unknown.  Please ensure the variable is defined.


This is caused because when `-J-Duser.language=de -J-Duser.country=DE ` are specified to `jpackage.exe `, it will result with the following cultures in `light.exe` invocation: `-cultures:de-de`.

4. Continuing with the problem in "3.", I've tried to add `en-us` culture as a fallback one, and found that it is not possible, `light.exe` fails with the following:


light.exe : error LGHT0100 : The localization identifier 'message.install.dir.exist' has been duplicated in multiple locations.  Please resolve the conflict.

when `-cultures:de-de;en-us` is specified to it.

5. `Culture` names in all primary `.wxl` files except `en-us` are specified using only "language" part, like `de`. I've found that this usage works correctly, when only `WixUtilExtension` is used (default jpackage behaviour), but it is not accepted by `light.exe` when `WixUIExtension` is also used, it fails like this (not Wix-internal build-time paths):


    C:\agent_work\66\s\src\ext\UIExtension\wixlib\BrowseDlg.wxs(10) : error LGHT0102 : The localization variable !(loc.WixUIOK) is unknown.  Please ensure the variable is defined.
    C:\agent_work\66\s\src\ext\UIExtension\wixlib\BrowseDlg.wxs(14) : error LGHT0102 : The localization variable !(loc.WixUICancel) is unknown.  Please ensure the variable is defined.
    C:\agent_work\66\s\src\ext\UIExtension\wixlib\BrowseDlg.wxs(18) : error LGHT0102 : The localization variable !(loc.BrowseDlgComboLabel) is unknown.  Please ensure the variable is defined.

It is not clear, why exactly this is happening, I've found it is possible to fix this by using `Culture` names in primary `.wxl` files in exactly the same form as in Wix internal `.wxl` files, like in [WixUI_de-de.wxl](https://github.com/jef-n/wix3/blob/6b68e7f3601dfc35c3ee2a96510113585985b960/src/ext/UIExtension/wixlib/WixUI_de-de.wxl). I've updated cultures names in all primary `.wxl` files in the patch.

6. To cover "5." I've updated `WinL10nTest` adding runs with and without `WixUIExtension` for all primary cultures.

7. I assume this problem is not directly related to jpackage. I've found that `jpackage.exe` `--verbose` output for Japanese and Chinese locale runs is garbled when it is redirected to file:


[03:54:17.120] ?????? MSI ????? ???


I've found that if encoding is specified to std streams in -jpackage laucher here](https://github.com/openjdk/jdk/blob/37d3146cca2c40dd53fcebd9cb78595f018b3489/src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java#L50):

If these streams are changed to:


        PrintWriter out = new PrintWriter(System.out, false, StandardCharsets.UTF_8);
        PrintWriter err = new PrintWriter(System.err, false, StandardCharsets.UTF_8);


then redirected output in the file is correct. I am not sure whether this change makes sense (I understand that this is a console output, and console encoding handling will depend on Windows system locale, I used only `en-US` system locale), so I didn't include it in the patch. Maybe this is something to keep in mind for future with overall Windows move to better `UTF-8` support.

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From lancea at openjdk.org  Wed Aug 10 14:43:13 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Aug 2022 14:43:13 GMT
Subject: [jdk19] Integrated: 8288769: Revert unintentional change to deflate.c
In-Reply-To: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
References: <zyc31vhLBev_UBA_2bV1i1qVgPCsipNg9qc-WpxgvoU=.36814819-7ecb-427b-82eb-8def31765319@github.com>
Message-ID: <5t-dApSUrDzJB0RQb9WMKq0ag7_IUM1QtCWDBp6Ba2I=.65c0f452-64d2-4e8a-9510-113bafdadf0d@github.com>

On Wed, 3 Aug 2022 10:21:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this patch to deflate.c which reverts an unintentional change  that was part of  JDK-8284371, which reverted the reworking of (7) deflate.c undo (6), replaced withe the official zlib repo fix see#305/#f969409 
> 
> Mach5 tiers1-3 have been run without failure

This pull request has now been integrated.

Changeset: 4c6d22a6
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/4c6d22a6cee3d7f1da69e50dddec45158b33e331
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8288769: Revert unintentional change to deflate.c

Reviewed-by: iris, bpb, alanb

-------------

PR: https://git.openjdk.org/jdk19/pull/159

From alanb at openjdk.org  Wed Aug 10 15:34:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Aug 2022 15:34:39 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <Bghwv9PezXdZQJu-G5eTJ1gxdERwLxDliNUZh3Z2rs0=.69a99801-ffd7-41d4-aeb6-1439a6f9ee81@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <Bghwv9PezXdZQJu-G5eTJ1gxdERwLxDliNUZh3Z2rs0=.69a99801-ffd7-41d4-aeb6-1439a6f9ee81@github.com>
Message-ID: <o4zJ16Pq18EeblTzwsnp1S1YJDdncAlTMHsq5qziM2A=.f59deeae-54d7-4fcf-b488-95129bb0de6b@github.com>

On Sun, 7 Aug 2022 07:55:26 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
>> 
>> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>> 
>> A new test has been added which reproduces the issue and verifies the fix.
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2630:
> 
>> 2628:         int h = 0;
>> 2629:         for (Enum<?> e : enums) {
>> 2630:             h = h + Objects.hashCode(e.name()) * 43;
> 
> why * 43 ? Isn't String.hashCode good enough?

A sum of e.name().hashCode() should be okay here.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From alanb at openjdk.org  Wed Aug 10 15:34:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Aug 2022 15:34:42 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <L1YkpxSCwEHLP5jJXK56s5-CCBUhnKUdEQQHOT9gkLA=.49e068fb-41a0-4ae3-a9d7-96b011fbd2f3@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 71:

> 69:      */
> 70:     @Test
> 71:     public void testModifiersOrdering() throws Exception {

Are you planning to expand the test to cover Requires.Modifier and Exports.Modifier too?

test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 76:

> 74:         // important to use Set.of() (i.e. backed by immutable set) to reproduce the issue
> 75:         final Set<ModuleDescriptor.Opens.Modifier> mod1 = Set.of(
> 76:                 ModuleDescriptor.Opens.Modifier.SYNTHETIC, ModuleDescriptor.Opens.Modifier.MANDATED);

These should probably be "mods1" and "mods2" rather than "mod1" and "mod2" as they are a set of modifiers rather than a single modifier.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From asemenyuk at openjdk.org  Wed Aug 10 16:00:38 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 10 Aug 2022 16:00:38 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <J8Lv5wKEvtQ85TyzkvuRZN_cll9I4-XdAP-izjtU8yc=.e11cac82-7013-4253-aab7-d3f85840bac8@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

Thank you for the deep investigation and detailed report!

#2 issue was an oversight in `WinResources_*.properties` files. Thank you for catching it!

#7 I'm 100% sure not specifying character encoding in PrintWriter ctor was an oversight. The solution with specifying utf8 encoding looks good to me. Please file a separate CR for this issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From asemenyuk at openjdk.org  Wed Aug 10 16:05:35 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 10 Aug 2022 16:05:35 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <Ru8FM2nXlfREEgShGJzIBKexQPN38tOXJud2t-xrqD0=.1cccfbc5-6da4-42ea-bb78-94c268d3be3a@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From mchung at openjdk.org  Wed Aug 10 16:12:37 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 10 Aug 2022 16:12:37 GMT
Subject: RFR: 8291641: Optimize StackTraceElement.toString() [v8]
In-Reply-To: <quOLzexBGMfuQWsg8NdDxZ1ltQhyrPKMESk0uZgF_tU=.781df74c-4f62-451b-b3b7-b9d31749b6cf@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
 <quOLzexBGMfuQWsg8NdDxZ1ltQhyrPKMESk0uZgF_tU=.781df74c-4f62-451b-b3b7-b9d31749b6cf@github.com>
Message-ID: <wLto8W7NSBh-pmUfgG3W1DKobUA6D92N0N_4Yi_oBJo=.8b2c0c87-a80c-4a64-89db-451cff8f2aaf@github.com>

On Tue, 9 Aug 2022 20:26:43 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
>> 
>> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
>> 
>> Before
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
>> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
>> 
>> 
>> After
>> 
>> Benchmark                               Mode  Cnt       Score      Error  Units
>> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
>> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op
>
> David Schlosnagle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract constants, define & use `int length(@Nullable String s)`

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From duke at openjdk.org  Wed Aug 10 16:26:07 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 10 Aug 2022 16:26:07 GMT
Subject: Integrated: 8291641: Optimize StackTraceElement.toString()
In-Reply-To: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
References: <J5V8mwN_gbradynNitQRAp2y9_hvLcBCyUGTOQIIKmk=.2db091ce-b149-4f78-8315-66fc28d6849b@github.com>
Message-ID: <M8Se3UxB7uYWpBgnkVLey0HWEUdaidVZ_5dapN6tXlg=.b89a4c2a-1ee9-4423-9435-440a647cbff7@github.com>

On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <duke at openjdk.org> wrote:

> I would like to contribute an optimized version of `StackTraceElement#toString()` that uses a single StringBuilder throughout creation to avoid intermediate `String` allocations. `StackTraceElement#toString()` is used in a number of JDK code paths including `Throwable#printStackTrace()`, as well as many JDK consumers may transform `StackTraceElement` `toString()` in logging frameworks capturing throwables and exceptions, and diagnostics performing dumps.
> 
> Given this usage and some observed JFR profiles from production services, I'd like to reduce the intermediate allocations to reduce CPU pressure in these circumstances. I have added a couple benchmarks for a sample `Throwable#printStackTrace()` converted to String via `StringWriter` and individual `StackTraceElement` `toString`. The former shows ~15% improvement, while the latter shows ~40% improvement.
> 
> Before
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  167147.066 ? 4260.521  ns/op
> StackTraceElementBench.toString         avgt   15     132.781 ?    2.095  ns/op
> 
> 
> After
> 
> Benchmark                               Mode  Cnt       Score      Error  Units
> StackTraceElementBench.printStackTrace  avgt   15  142909.133 ? 2290.720  ns/op
> StackTraceElementBench.toString         avgt   15      78.939 ?    0.469  ns/op

This pull request has now been integrated.

Changeset: 9825c335
Author:    David Schlosnagle <davids at palantir.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9825c3356068feba8dde8217e8f8a56c9c573da4
Stats:     137 lines in 3 files changed: 121 ins; 4 del; 12 mod

8291641: Optimize StackTraceElement.toString()

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/9665

From joe.darcy at oracle.com  Wed Aug 10 16:56:32 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 10 Aug 2022 09:56:32 -0700
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <0sCoMJnKjMuDqah38a0n-pa_PxfpQfusjc19UmJGR80=.b8f729c8-f8e6-4bb1-8cb7-b59cc1b3e3aa@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <v_OWfLAWNiNej5iXxbd6EAipBgBX21Zx8XyiWu7HEas=.6c5119a3-ac72-4ae7-b96a-503715e3b842@github.com>
 <0sCoMJnKjMuDqah38a0n-pa_PxfpQfusjc19UmJGR80=.b8f729c8-f8e6-4bb1-8cb7-b59cc1b3e3aa@github.com>
Message-ID: <739fda39-2f39-5f57-6669-a248c8d3d1bf@oracle.com>


On 8/9/2022 11:56 PM, Peter Levart wrote:
> On Sun, 7 Aug 2022 08:14:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>
>>> Sorry for joining late. I noticed that modsHashCode is a private method and it takes Iterable as a parameter. But everywhere it is called, a Set is passed to it. So why not just calling the set.hashCode() and be done with it? It may be even more optimal in some cases.
>> There's a lot going on here as the hash code is generated at link time and we also want it to be reproducible across builds. We also had a CDS bug with the the way that Enum objects were archived - Ioi has fixed that in JDK 19 so we have one less thing to be concerned about now.
> Ah, I see. Enum.hashCode() is identity hash code. I have been beaten by that in the past and apparently this is a sore point for many. I wonder if it could be changed. Is unstable hashCode (accross JVM instances) a feature here or just unfortunate implementation detail?
>
We've gotten a few issues filed about Enum.hashCode() over the years, 
one more recent one is

 ??? JDK-8050217: Enum.hashCode() should return ordinal value for the 
enum, for better consistency

Current thinking per that issue is the present behavior is more of a 
feature than a bug.

-Joe


From duke at openjdk.org  Wed Aug 10 18:26:36 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 10 Aug 2022 18:26:36 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <p6IxQrP43QKmTZbmEcHTaaQwrF8xzY_U5B3Nq0apUxQ=.bdd0d08f-2901-4a0a-87fa-2cf9ac54c7ca@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> wrote:

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

It should be okay to remove the GC settings for these tests. I am just wondering how it would impact the test coverage in ATR. Let me bring this up to the SQE team.

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From lmesnik at openjdk.org  Wed Aug 10 18:29:36 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Aug 2022 18:29:36 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <3Mg1niwPI-4uyEH9ifLqN0ERzNGdNNcl7_w4_gfyfMw=.f42f8f15-1237-41d1-ba80-2a7cd9f72ead@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> wrote:

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

We should run these tests with differrent GC in CI.

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From duke at openjdk.org  Wed Aug 10 18:34:35 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 10 Aug 2022 18:34:35 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <GkofIESgeAqIj_6Z6MfiS0oq4i2VSJ6xCBy5mMv4Tgs=.2686d713-51fe-49f8-b8a0-0a2ebde9d228@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> wrote:

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

It sounds good to me as long as we don't lose coverage. I will update the scripts.

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From duke at openjdk.org  Wed Aug 10 18:50:51 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 10 Aug 2022 18:50:51 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v2]
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Removed GC settings.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9813/files
  - new: https://git.openjdk.org/jdk/pull/9813/files/2fa6e2f8..75e7f722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=00-01

  Stats: 33 lines in 4 files changed: 0 ins; 31 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9813.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813

PR: https://git.openjdk.org/jdk/pull/9813

From akasko at openjdk.org  Wed Aug 10 18:59:47 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 18:59:47 GMT
Subject: RFR: 8291924: jpackage: l10n for Windows context menu label [v3]
In-Reply-To: <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
 <UNJpfq-Y-Weu4svgkKL1ukiCvXhieQoor5tCQzcqyIw=.7ae4e828-9844-494e-9cc2-a983ecd3923d@github.com>
Message-ID: <82uI2dBiccAOyNacCcTRMVztmsy8C-ixx5KCDz20mwQ=.9dc6d644-b7c2-44e6-84df-232cb0599edc@github.com>

On Mon, 8 Aug 2022 19:52:41 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
>> 
>> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
>> 
>> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
>> 
>> Testing:
>> 
>>  - [x] ran `FileAssociationsTest` with `install` enabled
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add english entries to l10n files

I've verified that there is no fallback to EN for `.wxl` files (more details in [this comment](https://github.com/openjdk/jdk/pull/9780#issuecomment-1210685780)), so leaving EN entries that were added to all `.wxl` files.

-------------

PR: https://git.openjdk.org/jdk/pull/9753

From akasko at openjdk.org  Wed Aug 10 19:05:28 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 19:05:28 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <vRantiFS5u-gmGSLoW2eiRcl7XFP7j7_lL_FlUXzhl8=.1ba42692-8886-4ee9-8bae-b392f812da8c@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

Thanks for the review! I assume this PR still needs a l10n review from @naotoj before integrating it?

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From akasko at openjdk.org  Wed Aug 10 19:20:25 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 19:20:25 GMT
Subject: Integrated: 8291924: jpackage: l10n for Windows context menu label
In-Reply-To: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
References: <fCayukxr3_UoiEI3_tGSZJszFv9_0NJbO509zUeZFJU=.525e8440-e192-4dd0-819f-226c85e6e89a@github.com>
Message-ID: <qbuJJdW15kGDYmSXSgSRLFAJj7EcPBl8mjyqIZnD8Jg=.f26f3b9c-bfce-4a1f-8b39-e33bc5592468@github.com>

On Thu, 4 Aug 2022 18:10:18 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change adds `ContextMenuCommandLabel` l10n property for file association context menu label. It is a follow-up to [this PR comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082).
> 
> Note, non-EN l10n values were filled using auto-translator and may need to be corrected.
> 
> To check the contents of the label, registry query is added to `PackageTest::addHelloAppFileAssociationsVerifier`.
> 
> Testing:
> 
>  - [x] ran `FileAssociationsTest` with `install` enabled

This pull request has now been integrated.

Changeset: e4925a39
Author:    Alex Kasko <akasko at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4925a3959c319028014437fdb393312bcb3627d
Stats:     18 lines in 7 files changed: 16 ins; 0 del; 2 mod

8291924: jpackage: l10n for Windows context menu label

Reviewed-by: naoto, asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/9753

From asemenyuk at openjdk.org  Wed Aug 10 19:21:35 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 10 Aug 2022 19:21:35 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <y-kXlUbwIAeRh6TeCh93nReEipnMjDUvBhNGdFyk0E8=.b6f3571e-e107-4306-b8a9-a7c6d2287f46@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

Agree. It would be good if @naotoj will look at it on more time.

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From naoto at openjdk.org  Wed Aug 10 19:34:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Aug 2022 19:34:33 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <S8gdwqQ0tIj3ykefz3aMAhWTMi8MXErgulKVG5d8oVM=.3e996cc7-2f07-4756-9fbc-dc331acb79f7@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

LGTM. Sorry for the delay.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9780

From mchung at openjdk.org  Wed Aug 10 19:47:35 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 10 Aug 2022 19:47:35 GMT
Subject: RFR: JDK-8291734: Return accurate ACC_SUPER access flag for
 classes
In-Reply-To: <KmGecD-ymlfsIy5mkToGcewYABclZs7OksOVQ_CysGw=.09665f4f-ae31-435d-aff5-af82e1a5f6a0@github.com>
References: <KmGecD-ymlfsIy5mkToGcewYABclZs7OksOVQ_CysGw=.09665f4f-ae31-435d-aff5-af82e1a5f6a0@github.com>
Message-ID: <8bpY7Sd6bKvVG7YlQUP-n2-SBUwabXeSGk_URYhoTdI=.deff423f-a3b5-4249-89a8-74acff31004d@github.com>

On Tue, 9 Aug 2022 00:15:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the ACC_SUPER information now available from a private getClassAccessFlagsRaw() method, the 
>  Set<AccessFlag> accessFlags() 
> method can properly model that setting.

Looks good to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9799

From darcy at openjdk.org  Wed Aug 10 19:59:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Aug 2022 19:59:10 GMT
Subject: Integrated: JDK-8291734: Return accurate ACC_SUPER access flag for
 classes
In-Reply-To: <KmGecD-ymlfsIy5mkToGcewYABclZs7OksOVQ_CysGw=.09665f4f-ae31-435d-aff5-af82e1a5f6a0@github.com>
References: <KmGecD-ymlfsIy5mkToGcewYABclZs7OksOVQ_CysGw=.09665f4f-ae31-435d-aff5-af82e1a5f6a0@github.com>
Message-ID: <bbSoulhvFhhJJ9Q3F19HwI-q-pRE9BYv-bT9tpsdjSk=.93bb381d-38bf-452d-a375-b4774c4ba594@github.com>

On Tue, 9 Aug 2022 00:15:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the ACC_SUPER information now available from a private getClassAccessFlagsRaw() method, the 
>  Set<AccessFlag> accessFlags() 
> method can properly model that setting.

This pull request has now been integrated.

Changeset: 68af7c13
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68af7c1365712773a56f19ce3453baebffd006f4
Stats:     21 lines in 2 files changed: 2 ins; 5 del; 14 mod

8291734: Return accurate ACC_SUPER access flag for classes

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/9799

From akasko at openjdk.org  Wed Aug 10 20:38:08 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 20:38:08 GMT
Subject: Integrated: 8291978: jpackage: allow to override primary l10n files on
 Windows
In-Reply-To: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
Message-ID: <G44FE-kXzo1EqMqpzrzZ4HOun_xj3BmxWp00-WlZVhk=.05616b95-6bd6-4ab9-a1f4-58fcb25062be@github.com>

On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
> 
> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
> 
> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
> 
> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
> 
> Testing:
> 
>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode

This pull request has now been integrated.

Changeset: 543163a0
Author:    Alex Kasko <akasko at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38
Stats:     152 lines in 11 files changed: 99 ins; 16 del; 37 mod

8291978: jpackage: allow to override primary l10n files on Windows

Reviewed-by: asemenyuk, almatvee, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From akasko at openjdk.org  Wed Aug 10 20:51:42 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 10 Aug 2022 20:51:42 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <I13czKRcQiNjD0YxAkuWW7AGVyYumZ01SWDC2XP6XOc=.28e3db32-c748-454b-80fd-2920e7c36fc5@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

About the point "7." above, I've experimented (on Windows Server 2016) with `cmd.exe` and codepages and found that existing behaviour of `jpackage.exe` is consistent with existing behaviour of `java.exe`.

For both `java.exe` and `jpackage.exe`, when "Active codepage" in `cmd.exe` is `437` (default `en-US`):


C:\Users\Administrator>chcp
Active code page: 437


Then if I set default JVM locale to `ja-JP` using `-Duser.language=ja` and `-Duser.country=JP`, then both output in console window and redirected file output will be garbled to question marks `??????`.

If I set the Windows system "Language for non-Unicode programs" to Japanese, then, after the reboot, active codepage in `cmd.exe` will be 932 (note also Japanese file separator):


C:?projects?openjdk?scripts>chcp
Active code page: 932


In this case running both `java.exe` and `jpackage.exe` with `ja-JP` JVM locale will cause Japanese output to be displayed correctly in the `cmd.exe`. And output redirected to file will also be written correctly in `Shift-JIS` encoding.

So I assume that existing behaviour is intended one and not filing the Jira issue now. Please let me know if it is still makes sense to file such Jira issue for `UTF-8` stdout (for example, for the future).

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From asemenyuk at openjdk.org  Wed Aug 10 21:12:42 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 10 Aug 2022 21:12:42 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <L6ifzuQCURfLpLxhxDN43lc2uA6mafDgqIOjALCqKh8=.e8cd6eb1-9375-4738-b5c7-81479dcf057c@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

I don't think it is good that the encoding of jpackage output depends on the default jvm encoding. It is convenient to know that the output is always in a specific encoding regardless of the values of `user.language` and `user.country` system properties. But this might not be the case of help and error output produced by jpackage.

Let's keep jpackage aligned with other JDK tools. Could you please check the behavior of `java`? How the output of `java --help` is encoded?

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From lmesnik at openjdk.org  Wed Aug 10 21:13:04 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Aug 2022 21:13:04 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v2]
In-Reply-To: <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
Message-ID: <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>

On Wed, 10 Aug 2022 18:50:51 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This task converts 5 shell tests below to java version. 
>> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
>> test/java/lang/management/MemoryMXBean/PendingAllGC.sh
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed GC settings.

Sorry, that I missed these comments first time. Now the code is much cleaner.

test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java line 39:

> 37:  * @summary Test low memory detection of non-heap memory pool
> 38:  *
> 39:  * @run build MemoryUtil

Not sure if you need this build, jtreg should build required files by itself.

test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java line 41:

> 39:  * @run build MemoryUtil
> 40:  *
> 41:  * @run main/othervm/timeout=600 -noclassgc -XX:MaxMetaspaceSize=32m

I would prefer to have multiply tests rather than multiply 'run' in single tests. It allow jtreg to fail only one test which fail and run them parallel.

test/jdk/java/lang/management/MemoryMXBean/MemoryManagement.java line 35:

> 33:  * @modules jdk.management
> 34:  * @build MemoryManagement MemoryUtil
> 35:  * @run main/othervm/timeout=600 -Xmn8m -XX:+IgnoreUnrecognizedVMOptions

Do we want to run this configuration without G1?  Might be separate runs and add requires?

-------------

Changes requested by lmesnik (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9813

From naoto at openjdk.org  Wed Aug 10 21:23:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Aug 2022 21:23:33 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
Message-ID: <navid4aFFCNd9fFMp7BXxDnO5NeMXMV3nJH880Z5sKo=.31651199-9e94-4ae0-ae33-2808edcd6bc6@github.com>

On Wed, 10 Aug 2022 13:12:57 GMT, Alex Kasko <akasko at openjdk.org> wrote:

>> This change is a follow-up to [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038).
>> 
>> Override implementation is based on [this comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886).
>> 
>> As suggested in [this comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) only English translation is provided for new `resource.wxl-file` label.
>> 
>> `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to be able to provide `--temp` and inspect the contents of `config` dir in verifier. It is not clear if `WindowsHelper` is an appropriate place for this utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` flag itself is only used on Windows.
>> 
>> Testing:
>> 
>>  - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to `light.exe` and additional `@Parameter` run that overrides one of the primary `.wxl` files
>>  - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode
>
> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes for bundling with different cultures

That's the expected behavior. Historically, we only support where user's locale and the system' locale match, otherwise such a garbled text would generate. Since Windows 10, they offer UTF-8 as the system encoding (still they claim it is beta), then all the out put is in UTF-8.

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From duke at openjdk.org  Wed Aug 10 21:24:35 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 10 Aug 2022 21:24:35 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v2]
In-Reply-To: <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
 <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>
Message-ID: <0PK8yhJEINzYjG9vsCpb7ceOk779HGn1x8o2hVOmt4U=.6049910f-3447-4b5a-acde-c1086ff62b5e@github.com>

On Wed, 10 Aug 2022 21:09:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed GC settings.
>
> test/jdk/java/lang/management/MemoryMXBean/MemoryManagement.java line 35:
> 
>> 33:  * @modules jdk.management
>> 34:  * @build MemoryManagement MemoryUtil
>> 35:  * @run main/othervm/timeout=600 -Xmn8m -XX:+IgnoreUnrecognizedVMOptions
> 
> Do we want to run this configuration without G1?  Might be separate runs and add requires?

It doesn't fail with other GC modes, but I agree that it is misleading. We can make it a separate test and add @requires.

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From asemenyuk at openjdk.org  Wed Aug 10 21:30:50 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 10 Aug 2022 21:30:50 GMT
Subject: RFR: 8291978: jpackage: allow to override primary l10n files on
 Windows [v3]
In-Reply-To: <navid4aFFCNd9fFMp7BXxDnO5NeMXMV3nJH880Z5sKo=.31651199-9e94-4ae0-ae33-2808edcd6bc6@github.com>
References: <5QGhJUFNo7mT8gzyTLys6NcHD5L9DxWc_WX80Qmt6aM=.dee1beaf-e294-4ba6-9bb0-ca1522263aa1@github.com>
 <-x2Wx4pjNM8m8m5R8UipzR0cMtzu0N_O1Znhew2gngg=.23ec8a16-a9af-42a4-838a-af1015a3478b@github.com>
 <navid4aFFCNd9fFMp7BXxDnO5NeMXMV3nJH880Z5sKo=.31651199-9e94-4ae0-ae33-2808edcd6bc6@github.com>
Message-ID: <_DXzbzYcvGGoAQvlON4ORKOJaXQWm2xWVDjB24lV784=.367fbc38-823b-49b2-88ff-6f92ba58311d@github.com>

On Wed, 10 Aug 2022 21:20:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixes for bundling with different cultures
>
> That's the expected behavior. Historically, we only support where user's locale and the system' locale match, otherwise such a garbled text would generate. Since Windows 10, they offer UTF-8 as the system encoding (still they claim it is beta), then all the out put is in UTF-8.

Thank you for the clarification, @naotoj ! I think the case is closed. @akashche, no need to bother with "7".

-------------

PR: https://git.openjdk.org/jdk/pull/9780

From duke at openjdk.org  Wed Aug 10 22:02:52 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 10 Aug 2022 22:02:52 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v3]
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Removed @build and move runs to separate tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9813/files
  - new: https://git.openjdk.org/jdk/pull/9813/files/75e7f722..b363daa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=01-02

  Stats: 25 lines in 2 files changed: 22 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9813.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813

PR: https://git.openjdk.org/jdk/pull/9813

From some-java-user-99206970363698485155 at vodafonemail.de  Wed Aug 10 23:24:42 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Thu, 11 Aug 2022 01:24:42 +0200
Subject: [BUG]Collections.unmodifiableMap(map).entrySet().iterator().forEachRemaining
 ismissing null check
In-Reply-To: <cc97ff3e7c6045459e0e7466b712efe5@vodafonemail.de>
Message-ID: <ae963decc60341bcb6738169ee8509e3@vodafonemail.de>

Hi,
could you please report this at https://bugreport.java.com/bugreport/
(please also first search at https://bugs.openjdk.org/issues?jql=project%3DJDK%20AND%20issuetype%3DBug
whether it has already been reported).

This also seems to affect the `CheckedEntrySet`; would be good if you could mention that
in your report as well.

I think the easiest reproducers for this can be created with an empty map:
```
Collections.unmodifiableMap(Map.of()).entrySet().iterator().forEachRemaining(null)
Collections.checkedMap(Map.of(), String.class, String.class).entrySet().iterator().forEachRemaining(null)
```
Per specification both calls should throw a NullPointerException, but they don't throw it.

Might also be worth recommending to the JDK authors to perform the null check in the internal
`entryConsumer` method to avoid having it repeated 4 times, once for each caller. The `CheckedEntrySet`
would still need a separate null check though.

Kind regards


From smarks at openjdk.org  Wed Aug 10 23:59:28 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 10 Aug 2022 23:59:28 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v2]
In-Reply-To: <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
 <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
Message-ID: <j9LCIi9Rn1yc2UflcS1DLNjEdODvZO62hEdwp9YeuIw=.0411d959-4c84-4d32-a9be-179ab5727145@github.com>

On Wed, 10 Aug 2022 02:54:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
>> 
>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - use assertThrows()

Thanks for following up on this. Looks good.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9806

From lmesnik at openjdk.org  Thu Aug 11 00:30:40 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 11 Aug 2022 00:30:40 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v3]
In-Reply-To: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
Message-ID: <dWV0R8zQjOsk0yJQlZSKWnkZoOzVCRQAzJ4vmVSM3h4=.1d4e3465-e6c3-4b59-b3ae-f25cbfca6a44@github.com>

On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This task converts 5 shell tests below to java version. 
>> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
>> test/java/lang/management/MemoryMXBean/PendingAllGC.sh
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @build and move runs to separate tests.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From duke at openjdk.org  Thu Aug 11 01:49:38 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 11 Aug 2022 01:49:38 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v7]
In-Reply-To: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
 <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com>
Message-ID: <hN5WeGgAmuOJi9RIJMru_p7J1iGgEeDs9i_ZHNllT78=.8231c8ba-b291-4b65-93c0-829b15cae359@github.com>

On Wed, 3 Aug 2022 09:18:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove line
>>  - add export
>
> What happened with the experiment to move ContainerInfoMXBean to jdk.management?

Hi, @AlanBateman 
I updated the code and move ContainerInfoMXBean to jdk.management
Can the CSR tag be removed?

-------------

PR: https://git.openjdk.org/jdk/pull/9372

From jpai at openjdk.org  Thu Aug 11 02:17:34 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Aug 2022 02:17:34 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v2]
In-Reply-To: <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
 <YeNtf0fDIsNWwCHh-ZUoVU2Hnk0nJMJHe2Sr1hMyfPM=.4f1d31a0-6a90-48f2-9605-972d03a6baea@github.com>
Message-ID: <t2wzgnYyPKoadGLIu3cSpfUS9EIDVIJGDGEBFue-rPg=.ebce7761-001d-4bc1-b447-100c1e40837e@github.com>

On Wed, 10 Aug 2022 02:54:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
>> 
>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - use assertThrows()

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/9806

From jpai at openjdk.org  Thu Aug 11 02:20:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Aug 2022 02:20:10 GMT
Subject: Integrated: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
References: <LRH1CHk97vmB9nDloUBJmGKV8GXRXdNKJyLmr2UWDOc=.a7e9cf93-638e-45bb-b881-54d0d2133b48@github.com>
Message-ID: <Z4sNqT4qKyV1aL0zKUSo7YfjNfPFFt3uOEQzSG_3iz4=.12c1d35a-186c-48a1-82ea-f0c74f2df663@github.com>

On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> (This is a recreation of a previous pull request which had received some reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that personal branch and recreate it due to some git issues)
> 
> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

This pull request has now been integrated.

Changeset: 4b03e135
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b03e135e157cb6cc9ba5eebf4a1f1b6e9143f48
Stats:     42 lines in 6 files changed: 40 ins; 1 del; 1 mod

8285405: add test and check for negative argument to HashMap::newHashMap et al

Reviewed-by: chegar, naoto, lancea, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/9806

From sspitsyn at openjdk.org  Thu Aug 11 03:13:45 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Aug 2022 03:13:45 GMT
Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell
 tests to java version [v3]
In-Reply-To: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
Message-ID: <CeTgWRfl_dZCiwQWTlRv6l0uE6NmCEmRMRF9vsEEeaM=.133b8b41-a68a-4bba-936b-c1afbde11580@github.com>

On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This task converts 5 shell tests below to java version. 
>> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
>> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
>> test/java/lang/management/MemoryMXBean/PendingAllGC.sh
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @build and move runs to separate tests.

Looks good to me.
Thank you for taking care about these tests!
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9813

From smarks at openjdk.org  Thu Aug 11 04:00:39 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 11 Aug 2022 04:00:39 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Revise Implementation Note discussing JNI Invocation API.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/c8b331f1..783b3b59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=04-05

  Stats: 13 lines in 1 file changed: 5 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

PR: https://git.openjdk.org/jdk/pull/9437

From smarks at openjdk.org  Thu Aug 11 04:03:03 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 11 Aug 2022 04:03:03 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <5q4e6sv6jbOuaw0CQRCYhhk-Iq6G41Y7uz7vaU_NOaY=.2d66481b-c25b-43c4-a1c3-29d84fd21505@github.com>
Message-ID: <B9WN6Xkmqh2S2G7ONoQzdx1FKNr_GCDfdz0U_jTvXZ8=.57fb1c19-7f75-4f0d-af8a-feaca9ebba0c@github.com>

On Mon, 8 Aug 2022 02:27:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More edits from Alex's suggestions.
>
> src/java.base/share/classes/java/lang/Runtime.java line 99:
> 
>> 97:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">DestroyJavaVM</a>.
>> 98:  * This function is responsible for initiating the shutdown sequence when the number of running
>> 99:  * ({@linkplain Thread#isAlive() live}) non-daemon threads first drops to zero. When the shutdown
> 
> I think we need to align this more with the proposed text of JLS 12.8. It needs to be clearer that `DestroyJavaVM` must be used in conjunction with `CreateJavaVM` to get the desired termination behaviour. Otherwise, the proposed text allows for the possibility that the JVM will always terminate when the last non-daemon thread terminates, even if `DestroyJavaVM` has not been called. It needs to be clear that if the JVM is started by the JNI Invocation API, then it must also be terminated by the JNI invocationAPI to get the required behaviour.

@dholmes-ora OK I've updated the implementation note to try to make it quite clear that the shutdown-at-zero-non-daemon-threads behavior is tied to `DestroyJavaVM`. (This is good; I didn't know this before I embarked on this exercise of updating these specs!) I'm not entirely sure of the state of JLS 12.8, but if I know Alex :-) it's unlikely to change much, and I think this section is consistent with it.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: Integrated: Merge jdk19
Message-ID: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>

Forward port JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8288769: Revert unintentional change to deflate.c
 - 8291496: Allocating card table before heap causes underflow asserts in CardTable::addr_for()
 - 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9828/files
  Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/9828.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9828/head:pull/9828

PR: https://git.openjdk.org/jdk/pull/9828

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
References: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
Message-ID: <tDsmxM0i7TDUsE501WbVPMDEMsZb2_d1PaZb84pVJQI=.4b33399d-425a-44ee-a1b3-ea91f25f487e@github.com>

On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 85a60235
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4
Stats:     686 lines in 44 files changed: 89 ins; 540 del; 57 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9828

From dholmes at openjdk.org  Thu Aug 11 07:20:40 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 07:20:40 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]
In-Reply-To: <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
Message-ID: <4V4svWBj4q2aKuNe2vzgCDR2l5x4hOqoC9i3jDR4i9A=.a8febb5e-be20-4956-ba15-432f7c85dd51@github.com>

On Thu, 11 Aug 2022 04:00:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise Implementation Note discussing JNI Invocation API.

src/java.base/share/classes/java/lang/Runtime.java line 99:

> 97:  * <a href="{@docRoot}/../specs/jni/invocation.html">JNI Invocation API</a>
> 98:  * to control launching and termination of the JVM. Such native code invokes the
> 99:  * <a href="{@docRoot}/../specs/jni/invocation.html#jni_createjavavm">{@code JNI_CreateJavaVM}</a>

JNI {@code CreateJavaVM}

src/java.base/share/classes/java/lang/Runtime.java line 101:

> 99:  * <a href="{@docRoot}/../specs/jni/invocation.html#jni_createjavavm">{@code JNI_CreateJavaVM}</a>
> 100:  * function to launch the JVM. Subsequently, the native code invokes the
> 101:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">{@code DestroyJavaVM}</a>

JNI {@code DestroyJavaVM}

to be consistent; or drop JNI from both.

src/java.base/share/classes/java/lang/Runtime.java line 103:

> 101:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">{@code DestroyJavaVM}</a>
> 102:  * function to await termination of that JVM. The {@code DestroyJavaVM} function is responsible for
> 103:  * initiating the shutdown sequence when the number of {@linkplain Thread#isAlive() running}

s/running/live

"live" is consistent with Thread terminology

src/java.base/share/classes/java/lang/Runtime.java line 107:

> 105:  * terminates, control is returned to the native code that invoked {@code DestroyJavaVM}.
> 106:  * <p>
> 107:  * This differs from the {@link #exit exit} or {@link #halt halt} methods. These methods typically

In a new paragraph it is not clear what "This" refers to. I would run this into the previous paragraph as:

> This behavior differs from the {@link #exit exit} or {@link #halt halt} methods, which typically terminate the OS process hosting the JVM and do not interact with the JNI Invocation API.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From dholmes at openjdk.org  Thu Aug 11 07:27:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 07:27:29 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <FM7sQqMq6aYLngEIKR3d1rEAB4cr48JvRux0xQvhum0=.d79d145b-2413-4933-9430-a0eb9d5154d2@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
 <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>
 <BX_UHsETk2nbNMcvFM0y2_sP90IRCfUZtSj-0SoJw40=.b0719da1-dedf-4273-bd61-838b643d1b1b@github.com>
 <FM7sQqMq6aYLngEIKR3d1rEAB4cr48JvRux0xQvhum0=.d79d145b-2413-4933-9430-a0eb9d5154d2@github.com>
Message-ID: <GiO4NCVFu-WoXJVfQbJ8JXaZ4T5kSrRUIUJvYSMioQ0=.b33c6355-382a-4eb1-aaa0-9b154f924628@github.com>

On Tue, 9 Aug 2022 13:56:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thread.State was added (in Java 5) for monitoring and management purposes, it's not an API that most libraries or programs would use. It could be introduced in the class description and referenced from other APIs that change/test the state but it would encourage use beyond the original intent.
>
> What you have is okay although I would have preferred if the sentence on the join method was in the previous paragraph rather as it fits with termination.

Plus one on the join() bit. You could also argue for mentioning isAlive() here too.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From dfuchs at openjdk.org  Thu Aug 11 10:39:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Aug 2022 10:39:42 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]
In-Reply-To: <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
Message-ID: <NTqD8AGbaS3c2uTKVFxgg8bAcONc4kwogiBj4wHNwfc=.81e9bebd-75d3-4590-abb2-2e0f32790d6c@github.com>

On Thu, 11 Aug 2022 04:00:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise Implementation Note discussing JNI Invocation API.

src/java.base/share/classes/java/lang/Runtime.java line 197:

> 195:      * as possible. They should also not rely blindly upon services that may
> 196:      * have registered their own shutdown hooks and therefore may themselves in
> 197:      * the process of shutting down. Attempts to use other thread-based

Is there a "be" missing here? 
> may themselves *be* in the process ...

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From jpai at openjdk.org  Thu Aug 11 14:16:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Aug 2022 14:16:51 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v2]
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  incorporate review comments and add more testing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9790/files
  - new: https://git.openjdk.org/jdk/pull/9790/files/13af6b83..4933e6d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9790&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9790&range=00-01

  Stats: 98 lines in 2 files changed: 85 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9790/head:pull/9790

PR: https://git.openjdk.org/jdk/pull/9790

From jpai at openjdk.org  Thu Aug 11 14:16:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Aug 2022 14:16:52 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <TT42O5xfIxHntrTEwsjNMfh0PrEBlQoBR2W47xO7Gk4=.b125ec87-418a-4649-8b5d-41a7c9d8ad09@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

Hello Alan, Peter, you are right - the hashcode computation and do away with the `* 43` part. I've updated this PR to do that change. I've also updated the tests to add coverage for the exports and requires modifiers as suggested by Alan.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From jpai at openjdk.org  Thu Aug 11 14:16:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Aug 2022 14:16:52 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v2]
In-Reply-To: <L1YkpxSCwEHLP5jJXK56s5-CCBUhnKUdEQQHOT9gkLA=.49e068fb-41a0-4ae3-a9d7-96b011fbd2f3@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <L1YkpxSCwEHLP5jJXK56s5-CCBUhnKUdEQQHOT9gkLA=.49e068fb-41a0-4ae3-a9d7-96b011fbd2f3@github.com>
Message-ID: <dZpbDokxPQFQM61o8qM55OqX3JKGnqZpsfu46hAMtIU=.20d42023-c671-40f0-b0d4-fbed93459fe2@github.com>

On Wed, 10 Aug 2022 15:23:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   incorporate review comments and add more testing
>
> test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 76:
> 
>> 74:         // important to use Set.of() (i.e. backed by immutable set) to reproduce the issue
>> 75:         final Set<ModuleDescriptor.Opens.Modifier> mod1 = Set.of(
>> 76:                 ModuleDescriptor.Opens.Modifier.SYNTHETIC, ModuleDescriptor.Opens.Modifier.MANDATED);
> 
> These should probably be "mods1" and "mods2" rather than "mod1" and "mod2" as they are a set of modifiers rather than a single modifier.

Fixed in the latest version of this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From duke at openjdk.org  Thu Aug 11 14:38:34 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 11 Aug 2022 14:38:34 GMT
Subject: Integrated: JDK-8292064 Convert java/lang/management/MemoryMXBean
 shell tests to java version
In-Reply-To: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <2lsSCwEjUh2Q6JFbJkcgOMCzo_Rt6BF1x8w-yhDalwg=.9949ffa6-854a-4e48-a1f8-8a4a76a398e0@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> wrote:

> This task converts 5 shell tests below to java version. 
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh 
> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh 
> test/java/lang/management/MemoryMXBean/PendingAllGC.sh

This pull request has now been integrated.

Changeset: 7ea9ba1f
Author:    Bill Huang <bill.w.huang at oracle.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ea9ba1f6c18ace5aa0896ab8676926fdc0d64ea
Stats:     346 lines in 9 files changed: 37 ins; 303 del; 6 mod

8292064: Convert java/lang/management/MemoryMXBean shell tests to java version

Reviewed-by: lmesnik, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/9813

From dcubed at openjdk.org  Thu Aug 11 20:10:37 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 11 Aug 2022 20:10:37 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,int) in 5000ms"
Message-ID: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>

A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
when waiting for a compilation to finish.

-------------

Commit messages:
 - 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with "AssertionError: Failed to compile int Fuzz.com_int(int,int) in 5000ms"

Changes: https://git.openjdk.org/jdk/pull/9844/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290211
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9844.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9844/head:pull/9844

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Thu Aug 11 20:19:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 11 Aug 2022 20:19:50 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
Message-ID: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>

Split the java/util/stream/SpinedBufferTest.java test into two parts:
- java/util/stream/SpinedBufferTest1.java has the first 6 test cases
- java/util/stream/SpinedBufferTes2.java has the second 6 test cases

I couldn't figure out a way to set a larger timeout value for the entirety
of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
this problem with testng tests by splitting the test into more parts.

This fix is being tested in my jdk-20+10 stress testing run.

-------------

Commit messages:
 - 8292215: java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java times out with slowdebug

Changes: https://git.openjdk.org/jdk/pull/9845/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292215
  Stats: 797 lines in 3 files changed: 427 ins; 370 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9845.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9845/head:pull/9845

PR: https://git.openjdk.org/jdk/pull/9845

From duke at openjdk.org  Thu Aug 11 21:21:23 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 11 Aug 2022 21:21:23 GMT
Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh
 to java version
Message-ID: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>

This task converts 2 shell tests to java version. 
test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh 
test/java/lang/management/RuntimeMXBean/TestInputArgument.sh

-------------

Commit messages:
 - Updated copyright header.
 - Converted TestInputArgument.sh to java version.
 - Coverted TestSystemLoadAvg shell test to java version.

Changes: https://git.openjdk.org/jdk/pull/9848/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292066
  Stats: 200 lines in 4 files changed: 43 ins; 144 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/9848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9848/head:pull/9848

PR: https://git.openjdk.org/jdk/pull/9848

From lmesnik at openjdk.org  Fri Aug 12 03:47:30 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 Aug 2022 03:47:30 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <hgfbq99cC78RSyy5GF_GfD3vBHdhlf3qQurqHfw178U=.02f38df7-24e3-44f2-a78c-73055f9e9700@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From jiefu at openjdk.org  Fri Aug 12 04:08:26 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 12 Aug 2022 04:08:26 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <6RTi6GrCdJSXUUyxF3BrQwc2CFEGkxFp3fxmfN5UL8I=.8d8424ec-a8c5-4a53-aab5-a3a78b43a9c6@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 81:

> 79:     static final boolean VERBOSE = false;
> 80: 
> 81:     static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

How about something like this?

System.getProperty("test.timeout.factor", "5.0")

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From jiefu at openjdk.org  Fri Aug 12 04:08:27 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 12 Aug 2022 04:08:27 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <6RTi6GrCdJSXUUyxF3BrQwc2CFEGkxFp3fxmfN5UL8I=.8d8424ec-a8c5-4a53-aab5-a3a78b43a9c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <6RTi6GrCdJSXUUyxF3BrQwc2CFEGkxFp3fxmfN5UL8I=.8d8424ec-a8c5-4a53-aab5-a3a78b43a9c6@github.com>
Message-ID: <CBQrOkAkL8FFtKJtLNa3hVUQ-98x55y1Rf5mxszLu-8=.ab36a581-b2f9-4507-ac27-1f3b23ba0a33@github.com>

On Fri, 12 Aug 2022 04:03:56 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 81:
> 
>> 79:     static final boolean VERBOSE = false;
>> 80: 
>> 81:     static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
> 
> How about something like this?
> 
> System.getProperty("test.timeout.factor", "5.0")

Or


static final int COMPILATION_TIMEOUT = max((int)(1_000 * timeoutFactor), 5_000); // ms

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From alanb at openjdk.org  Fri Aug 12 13:43:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 13:43:12 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <0k6ztY-UbHlAyXODCw6OCsLOjWlxgOO_9xWpBSeCtmU=.6b1ca674-b09f-42e9-b8ca-842f493e1867@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From alanb at openjdk.org  Fri Aug 12 13:52:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 13:52:56 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
Message-ID: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>

Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

-------------

Commit messages:
 - Convert to TestNG and run all tests on a virtual thread
 - Merge
 - Change test to use custom scheduler, easier to test reliably

Changes: https://git.openjdk.org/jdk/pull/9819/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9819&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292051
  Stats: 153 lines in 2 files changed: 54 ins; 57 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9819.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9819/head:pull/9819

PR: https://git.openjdk.org/jdk/pull/9819

From plevart at openjdk.org  Fri Aug 12 13:52:56 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 12 Aug 2022 13:52:56 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
In-Reply-To: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
Message-ID: <Xte1JwUFIe4X34rlLvWaLV-hhgrqMX6bms1FgR2HCXo=.e175d6df-7c92-49ef-a0ed-e4d965ff4f7b@github.com>

On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

Now that we have control over termination of carrier thread which can be stopped at will without waiting for 30s or more, we can again test all cases even with virtual threads...

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 145:

> 143:         // wait for carrier to terminate
> 144:         Thread carrier = carrierRef.get();
> 145:         carrier.join();

...would `close()`-ing the `pool` already guarantee that all pool thread(s) are already stopped? `join()` would not be needed then. But the spec. only talks about tasks that finish execution, not about threads...

-------------

Changes requested by plevart (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9819

From alanb at openjdk.org  Fri Aug 12 13:52:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 13:52:56 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
In-Reply-To: <Xte1JwUFIe4X34rlLvWaLV-hhgrqMX6bms1FgR2HCXo=.e175d6df-7c92-49ef-a0ed-e4d965ff4f7b@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
 <Xte1JwUFIe4X34rlLvWaLV-hhgrqMX6bms1FgR2HCXo=.e175d6df-7c92-49ef-a0ed-e4d965ff4f7b@github.com>
Message-ID: <7ynciPSg3pG4T57s1nKsq_zkKzt5GUJjqq1aDalJu7U=.3230ab1c-f090-4f12-922d-32b0df1c8355@github.com>

On Thu, 11 Aug 2022 08:26:12 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Now that we have control over termination of carrier thread which can be stopped at will without waiting for 30s or more, we can again test all cases even with virtual threads...

Yes, we can. I'll convert the test to run as a TestNG test and we can use a data provider for that.

> test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 145:
> 
>> 143:         // wait for carrier to terminate
>> 144:         Thread carrier = carrierRef.get();
>> 145:         carrier.join();
> 
> ...would `close()`-ing the `pool` already guarantee that all pool thread(s) are already stopped? `join()` would not be needed then. But the spec. only talks about tasks that finish execution, not about threads...

The close method waits for the all tasks to finish. There is a small window between task completion and the thread termination.

-------------

PR: https://git.openjdk.org/jdk/pull/9819

From openjdk at icemanx.nl  Fri Aug 12 14:05:16 2022
From: openjdk at icemanx.nl (Rob Spoor)
Date: Fri, 12 Aug 2022 16:05:16 +0200
Subject: [BUG]Collections.unmodifiableMap(map).entrySet().iterator().forEachRemaining
 ismissing null check
In-Reply-To: <ae963decc60341bcb6738169ee8509e3@vodafonemail.de>
References: <ae963decc60341bcb6738169ee8509e3@vodafonemail.de>
Message-ID: <58d3e531-515b-2aa1-9f27-ffa8e5fc8fe6@icemanx.nl>

I found one similar issue, https://bugs.openjdk.org/browse/JDK-8015008, 
but that was for an empty primitive iterator. I've created a bug report 
with id 9073784.


On 11/08/2022 01:24, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
> Hi,
> could you please report this at https://bugreport.java.com/bugreport/
> (please also first search at https://bugs.openjdk.org/issues?jql=project%3DJDK%20AND%20issuetype%3DBug
> whether it has already been reported).
> 
> This also seems to affect the `CheckedEntrySet`; would be good if you could mention that
> in your report as well.
> 
> I think the easiest reproducers for this can be created with an empty map:
> ```
> Collections.unmodifiableMap(Map.of()).entrySet().iterator().forEachRemaining(null)
> Collections.checkedMap(Map.of(), String.class, String.class).entrySet().iterator().forEachRemaining(null)
> ```
> Per specification both calls should throw a NullPointerException, but they don't throw it.
> 
> Might also be worth recommending to the JDK authors to perform the null check in the internal
> `entryConsumer` method to avoid having it repeated 4 times, once for each caller. The `CheckedEntrySet`
> would still need a separate null check though.
> 
> Kind regards
> 


From bpb at openjdk.org  Fri Aug 12 14:59:44 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 14:59:44 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
Message-ID: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>

On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

-------------

Commit messages:
 - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160"

Changes: https://git.openjdk.org/jdk/pull/9856/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291911
  Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9856.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9856/head:pull/9856

PR: https://git.openjdk.org/jdk/pull/9856

From bpb at openjdk.org  Fri Aug 12 14:59:44 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 14:59:44 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <8KpJsYoqzxUmTJO6nVpVvhlQHzncKoXAROeG_bWt-nQ=.4ccbaf22-f30d-4534-b2cb-4bb8793e5b67@github.com>

On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

Passed on 20 arbitrary nodes and on one where it failed previously due to user disk quotas.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From bpb at openjdk.org  Fri Aug 12 15:15:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 15:15:17 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <FpWbLjYzZQt7fqNs-XUmqAnxZpHkN75XsOSQfQjm0Hw=.cfe5262d-12a3-41f5-9d5c-3df39ac1c1e5@github.com>

On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

test/jdk/java/io/File/GetXSpace.java line 244:

> 242:                 // reported by df might be less that the actual total space in
> 243:                 // the store, but the free space should be the same.
> 244:                 if (!(Platform.isWindows() && ts > s.total && fs == s.free())) {

Unsure of the conditional here, in particular whether `fs == s.free()` is needed. Also, when failure is suppressed here, an informational print might be useful.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From dcubed at openjdk.org  Fri Aug 12 16:32:17 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 16:32:17 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <r9YFdk-_vCe-0-uHopha0agUCRAObGHkGbPXb9LUPu4=.94f58bc1-b903-4332-b439-093f1883a12e@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

@lmesnik, @DamonFool and @AlanBateman - Thanks for the reviews.

test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 82:

> 80: 
> 81:     static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
> 82:     static final int COMPILATION_TIMEOUT = (int)(1_000 * timeoutFactor); // ms

I was really hoping that `1_000 * timeoutFactor` would do the trick,
but stress run-#1 on my macosx-aarch64 machine had a couple of
sub-test timeouts at 12 seconds (1_000 * 12.0). My timeoutFactor
for slowdebug is 12.0. My linux-x64 machine passed stress run-#1
without any failures.

I've switched the value from 1_000 back to 5_000 for the next two
stress runs on both machines.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Fri Aug 12 16:32:19 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 16:32:19 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <hgfbq99cC78RSyy5GF_GfD3vBHdhlf3qQurqHfw178U=.02f38df7-24e3-44f2-a78c-73055f9e9700@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <hgfbq99cC78RSyy5GF_GfD3vBHdhlf3qQurqHfw178U=.02f38df7-24e3-44f2-a78c-73055f9e9700@github.com>
Message-ID: <vYqSmLbNcyED-3SkWP_xhzpZYNC3jRpvRsRsviSqS6k=.4fd74a4f-e6ea-48ec-afa2-4a11a9a66b70@github.com>

On Fri, 12 Aug 2022 03:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik, @DamonFool and @AlanBateman - Thanks for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Fri Aug 12 16:32:20 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 16:32:20 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <CBQrOkAkL8FFtKJtLNa3hVUQ-98x55y1Rf5mxszLu-8=.ab36a581-b2f9-4507-ac27-1f3b23ba0a33@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <6RTi6GrCdJSXUUyxF3BrQwc2CFEGkxFp3fxmfN5UL8I=.8d8424ec-a8c5-4a53-aab5-a3a78b43a9c6@github.com>
 <CBQrOkAkL8FFtKJtLNa3hVUQ-98x55y1Rf5mxszLu-8=.ab36a581-b2f9-4507-ac27-1f3b23ba0a33@github.com>
Message-ID: <Ms4xb_BC6s3xkdCm5WHXULCXoP26K_Eygv1YxPD30Bw=.432aa91f-332f-4390-a36f-eaf72da65aec@github.com>

On Fri, 12 Aug 2022 04:05:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 81:
>> 
>>> 79:     static final boolean VERBOSE = false;
>>> 80: 
>>> 81:     static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
>> 
>> How about something like this?
>> 
>> System.getProperty("test.timeout.factor", "5.0")
>
> Or
> 
> 
> static final int COMPILATION_TIMEOUT = max((int)(1_000 * timeoutFactor), 5_000); // ms

> System.getProperty("test.timeout.factor", "5.0")

Definitely not. Traditional default value for no specified timeoutFactor value is 1.0.

> static final int COMPILATION_TIMEOUT = max((int)(1_000 * timeoutFactor), 5_000); // ms

So you're trying to make sure we have a minimum COMPILATION_TIMEOUT value of 5 seconds,
but I'm not sure why you want that.


static final int COMPILATION_TIMEOUT = (int)(5_000 * timeoutFactor); // ms


i.e., a `default value * timeoutFactor` is the usual way to do this. I've seen some
folks use a timeoutFactor of 0.5 on really fast machines, but that wouldn't work
with your minimum COMPILATION_TIMEOUT value of 5 seconds above.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From cstein at openjdk.org  Fri Aug 12 16:34:43 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Aug 2022 16:34:43 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup required
 permissions for jtreg version 7 jar
Message-ID: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>

Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.

Find details in https://bugs.openjdk.org/browse/JDK-8292182

-------------

Commit messages:
 - 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup required permissions for jtreg version 7 jar

Changes: https://git.openjdk.org/jdk/pull/9857/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292182
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9857.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9857/head:pull/9857

PR: https://git.openjdk.org/jdk/pull/9857

From joehw at openjdk.org  Fri Aug 12 16:40:20 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 12 Aug 2022 16:40:20 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <J3X2O_n3rjNZFzU_xHqaWbOFeeh1YDYv-rz9C2Xc_ms=.d3ed582c-86c6-4d18-8c8d-855e9d65bc9a@github.com>

On Fri, 12 Aug 2022 16:26:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

Thanks for making it to work with jtreg 7!

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9857

From lancea at openjdk.org  Fri Aug 12 17:02:16 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 Aug 2022 17:02:16 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <7YealY6nApMsm6Vii15NeR4aY5LAJzaQo3jhr75nQh8=.c8b3cc23-8a20-4f82-b353-b23eeff5f2d9@github.com>

On Fri, 12 Aug 2022 16:26:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From iris at openjdk.org  Fri Aug 12 17:17:09 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 12 Aug 2022 17:17:09 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <Iec-wKqisyoQI9RB6P0HuwRMceeUV62BXg8IKH69XUE=.715a517c-f521-4fe0-926d-17b3b83798b2@github.com>

On Fri, 12 Aug 2022 16:26:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From ecaspole at openjdk.org  Fri Aug 12 18:28:12 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 12 Aug 2022 18:28:12 GMT
Subject: RFR: 8292196: Reduce runtime of java.util.regex microbenchmarks
Message-ID: <UarXS4dg6UO7RMbaCCQ13blAG1vxCFr9F-bB7nfST68=.ada2085f-0aa3-4573-a60d-4aeabb489e2e@github.com>

These changes reduce the run time to 45 minutes from about 1h40m with stability good enough for weekly promo build testing.

-------------

Commit messages:
 - 8292196: Reduce runtime of java.util.regex microbenchmarks

Changes: https://git.openjdk.org/jdk/pull/9861/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9861&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292196
  Stats: 27 lines in 4 files changed: 4 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9861.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9861/head:pull/9861

PR: https://git.openjdk.org/jdk/pull/9861

From naoto at openjdk.org  Fri Aug 12 20:21:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Aug 2022 20:21:30 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <PKozdsKPOnZKZKj9mB2-DKY9_PwgEWXt9Li-fSOg2PI=.dfab092f-4201-49b7-ac55-4c295dc60094@github.com>

On Fri, 12 Aug 2022 16:26:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

LGTM

test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java line 27:

> 25: 
> 26: import java.net.URL;
> 27: import java.nio.file.Path;

Nit: leftover import?

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9857

From cstein at openjdk.org  Fri Aug 12 20:41:24 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Aug 2022 20:41:24 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v2]
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <wuWPudCJsWE7-qgX1IZcj24CpHR8YPf8wEF2ms8w1i0=.b94896f2-e76c-477f-81b9-f9aa46df732c@github.com>

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import statement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9857/files
  - new: https://git.openjdk.org/jdk/pull/9857/files/f2046e67..0ca1a25c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9857&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9857&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9857.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9857/head:pull/9857

PR: https://git.openjdk.org/jdk/pull/9857

From cstein at openjdk.org  Fri Aug 12 20:41:26 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Aug 2022 20:41:26 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v2]
In-Reply-To: <PKozdsKPOnZKZKj9mB2-DKY9_PwgEWXt9Li-fSOg2PI=.dfab092f-4201-49b7-ac55-4c295dc60094@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
 <PKozdsKPOnZKZKj9mB2-DKY9_PwgEWXt9Li-fSOg2PI=.dfab092f-4201-49b7-ac55-4c295dc60094@github.com>
Message-ID: <XRp4HylNHXarlFImnwqz4cKyDeDUuzvcTqyn7rat7j0=.e56b25b0-f1c0-462e-90fd-69e5db464291@github.com>

On Fri, 12 Aug 2022 20:18:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused import statement
>
> test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java line 27:
> 
>> 25: 
>> 26: import java.net.URL;
>> 27: import java.nio.file.Path;
> 
> Nit: leftover import?

Yes. Removed the line.

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From jiefu at openjdk.org  Fri Aug 12 23:47:34 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 12 Aug 2022 23:47:34 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <Hx_PsN6tajqGm81_URYx_CcJEfYHY8WMdrMN_1zOcn4=.4e860bff-214c-4666-b27a-cf531950dd7a@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

> So you're trying to make sure we have a minimum COMPILATION_TIMEOUT value of 5 seconds,
but I'm not sure why you want that.

With the current patch, `COMPILATION_TIMEOUT` may become less than 5_000, which may lead to more failures on various platforms.
That's why I suggest let `COMPILATION_TIMEOUT >= 5_000`, which won't make things worse.

Thanks.

> Definitely not. Traditional default value for no specified timeoutFactor value is 1.0.

Okay, you're right.
This is because the timeoutFactor may be used by other tests too.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From duke at openjdk.org  Sat Aug 13 00:23:16 2022
From: duke at openjdk.org (duke)
Date: Sat, 13 Aug 2022 00:23:16 GMT
Subject: Withdrawn: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <53Dnge1Le-058leML_e2fyFDzIDV1dE_6yRcQJ3RXYk=.85fbb878-5f9b-4a40-a903-c337bb367bfd@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jpai at openjdk.org  Sat Aug 13 03:43:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 13 Aug 2022 03:43:13 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v2]
In-Reply-To: <wuWPudCJsWE7-qgX1IZcj24CpHR8YPf8wEF2ms8w1i0=.b94896f2-e76c-477f-81b9-f9aa46df732c@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
 <wuWPudCJsWE7-qgX1IZcj24CpHR8YPf8wEF2ms8w1i0=.b94896f2-e76c-477f-81b9-f9aa46df732c@github.com>
Message-ID: <t7C03WLd0SEFB93T5nj50QA0Y_kBOD2XUcEk4m8_V5U=.806e851a-96c9-437b-9fa8-a13e81e21ca5@github.com>

On Fri, 12 Aug 2022 20:41:24 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
>> 
>> Find details in https://bugs.openjdk.org/browse/JDK-8292182
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import statement

test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java line 217:

> 215:         URL loc = (cs == null) ? null : cs.getLocation();
> 216:         String path = (loc == null) ? null : loc.getPath();
> 217:         String name = (path == null) ? null : path.substring(path.lastIndexOf('/') + 1);

Is there a chance that this path could end with `/` and thus lead to a `IndexOutOfBoundsException` on this call to `substring`?

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From cstein at openjdk.org  Sat Aug 13 05:53:57 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 13 Aug 2022 05:53:57 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v2]
In-Reply-To: <t7C03WLd0SEFB93T5nj50QA0Y_kBOD2XUcEk4m8_V5U=.806e851a-96c9-437b-9fa8-a13e81e21ca5@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
 <wuWPudCJsWE7-qgX1IZcj24CpHR8YPf8wEF2ms8w1i0=.b94896f2-e76c-477f-81b9-f9aa46df732c@github.com>
 <t7C03WLd0SEFB93T5nj50QA0Y_kBOD2XUcEk4m8_V5U=.806e851a-96c9-437b-9fa8-a13e81e21ca5@github.com>
Message-ID: <lFkMtgoizo3hxZZXcvBA9Z70kPSKRz2Trt2hRqbUBiI=.aad3ccfe-d887-421d-8203-7e576e255792@github.com>

On Sat, 13 Aug 2022 03:41:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused import statement
>
> test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java line 217:
> 
>> 215:         URL loc = (cs == null) ? null : cs.getLocation();
>> 216:         String path = (loc == null) ? null : loc.getPath();
>> 217:         String name = (path == null) ? null : path.substring(path.lastIndexOf('/') + 1);
> 
> Is there a chance that this path could end with `/` and thus lead to a `IndexOutOfBoundsException` on this call to `substring`?

Yes. Usually the URL of the domain's code source points to a JAR file - but it is possible that a directory is the code source. Then the URL could end with a `/` character.

Will refactor the fix to use `Path::getFileName`.

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From cstein at openjdk.org  Sat Aug 13 06:10:42 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 13 Aug 2022 06:10:42 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v3]
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <B3MxWsnHWCk5wLauQphBM38cuU6lDxKxME4SywfpJgo=.a6c30780-4380-4edf-ae4f-1d97aa28b265@github.com>

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Make file name extraction more robust

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9857/files
  - new: https://git.openjdk.org/jdk/pull/9857/files/0ca1a25c..a9a690a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9857&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9857&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9857.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9857/head:pull/9857

PR: https://git.openjdk.org/jdk/pull/9857

From jwaters at openjdk.org  Sun Aug 14 15:45:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 Aug 2022 15:45:01 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12]
In-Reply-To: <QcPlrDuoMpsY7eSbuAYzkhNzW0SxXx1Qq29K-73EgoU=.ea471a6c-f05b-44b7-9a4b-9da80b0f975a@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
 <QcPlrDuoMpsY7eSbuAYzkhNzW0SxXx1Qq29K-73EgoU=.ea471a6c-f05b-44b7-9a4b-9da80b0f975a@github.com>
Message-ID: <cnQCZqPxw1nPKVGu1Ga31CECaisXsfdveznWRvFDXxE=.fbc9824f-cd2f-4ae6-8199-325a9197c241@github.com>

On Mon, 8 Aug 2022 18:02:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> JLI_ReportErrorMessageSys has a number of issues, as listed in the linked issue, since it's not widely used, it's easier to remove it and replace the areas it's called in with simpler calls to other error reporting functions:
>
> Julian Waters 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:
> 
>   Finalize Unix implementation, Windows to follow after

Closing in favour of a newer rewrite

-------------

PR: https://git.openjdk.org/jdk/pull/9793

From jwaters at openjdk.org  Sun Aug 14 15:45:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 Aug 2022 15:45:03 GMT
Subject: Withdrawn: 8292016: Rework JLI_ReportErrorMessageSys
In-Reply-To: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
References: <jabw-hQ8JJQuZdALr_dawWRCipXhr_fVG-rLLQ0w47k=.7426cbb3-88ef-4a66-90c8-6dc5d29ac75c@github.com>
Message-ID: <C9mJQoVuuHSRXv5na4UcVf0u6P6rnykArdv7xUioppo=.1bbfe463-9c2a-4e5e-889d-e53e15d7a6e3@github.com>

On Mon, 8 Aug 2022 04:23:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> JLI_ReportErrorMessageSys has a number of issues, as listed in the linked issue, since it's not widely used, it's easier to remove it and replace the areas it's called in with simpler calls to other error reporting functions:

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9793

From jwaters at openjdk.org  Sun Aug 14 17:01:31 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 Aug 2022 17:01:31 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys
Message-ID: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>

Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time (Clearing the error after the call, which is done in other areas of the JDK as well)

Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

-------------

Commit messages:
 - Split Windows API errors out of JLI_ReportErrorMessageSys
 - Whitespace
 - Implement platform specific sections
 - Whitespace
 - Comment should mention usage risks
 - First rework

Changes: https://git.openjdk.org/jdk/pull/9870/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292016
  Stats: 108 lines in 5 files changed: 72 ins; 21 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From xgong at openjdk.org  Mon Aug 15 01:13:58 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 15 Aug 2022 01:13:58 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <0Zw3xLOwMpG0T8_TkH6TEiyi5B6GtroI_QrE3Hl42JU=.6921ec98-fcee-437a-9161-a2577ca3946f@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <0Zw3xLOwMpG0T8_TkH6TEiyi5B6GtroI_QrE3Hl42JU=.6921ec98-fcee-437a-9161-a2577ca3946f@github.com>
Message-ID: <cS2iDUyNxM21KlNkHnguCv-QUgp2GkUgjESCsmeU-_g=.77e135fa-5bfe-413b-a049-4ac612ce6700@github.com>

On Thu, 4 Aug 2022 02:00:39 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
>> 
>> 
>> 1) mask = a.compare(0, ne);
>> 2) b = b.blend(0, mask);
>> 3) result = a | b;
>> 
>> 
>> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
>> 
>> A simpler implementation is:
>> 
>> 
>> 1) mask = a.compare(0, eq);
>> 2) result = a.blend(b, mask);
>> 
>> 
>> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
>> 
>> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
>> 
>> Benchmark                          (size) Mode  Cnt  Before    After    Units
>> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
>> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
>> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
>> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
>> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
>> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
>> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
>> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
>> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
>> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
>> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
>> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
>> 
>> We can also observe the similar improvement on x86 system.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266
>
> LGTM.

Thanks for the review @theRealELiu !

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From xgong at openjdk.org  Mon Aug 15 01:13:58 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 15 Aug 2022 01:13:58 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <YpycKW6nf5iKoi-NaYZ7x8MIi5GIIS86sPCdhmvGlP0=.0255a51c-52de-42c6-8671-114da5dd3cab@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

ping again. Could anyone please take a look at this simple patch? Thanks so much for your time!

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From dholmes at openjdk.org  Mon Aug 15 02:48:26 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Aug 2022 02:48:26 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]
In-Reply-To: <4V4svWBj4q2aKuNe2vzgCDR2l5x4hOqoC9i3jDR4i9A=.a8febb5e-be20-4956-ba15-432f7c85dd51@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
 <4V4svWBj4q2aKuNe2vzgCDR2l5x4hOqoC9i3jDR4i9A=.a8febb5e-be20-4956-ba15-432f7c85dd51@github.com>
Message-ID: <QuCF5574Ztexs2kwwYJWod9xTKsqbOWg6Yba4SnrvOw=.a8bf7909-2792-4ad6-bdc4-ea8f332ed2d3@github.com>

On Thu, 11 Aug 2022 06:49:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise Implementation Note discussing JNI Invocation API.
>
> src/java.base/share/classes/java/lang/Runtime.java line 99:
> 
>> 97:  * <a href="{@docRoot}/../specs/jni/invocation.html">JNI Invocation API</a>
>> 98:  * to control launching and termination of the JVM. Such native code invokes the
>> 99:  * <a href="{@docRoot}/../specs/jni/invocation.html#jni_createjavavm">{@code JNI_CreateJavaVM}</a>
> 
> JNI {@code CreateJavaVM}

Sorry that is a wrong comment from me. The API is not symmetric - it is `JNI_CreateJavaVM` but just `DestroyJavaVM`.

> src/java.base/share/classes/java/lang/Runtime.java line 101:
> 
>> 99:  * <a href="{@docRoot}/../specs/jni/invocation.html#jni_createjavavm">{@code JNI_CreateJavaVM}</a>
>> 100:  * function to launch the JVM. Subsequently, the native code invokes the
>> 101:  * <a href="{@docRoot}/../specs/jni/invocation.html#destroyjavavm">{@code DestroyJavaVM}</a>
> 
> JNI {@code DestroyJavaVM}
> 
> to be consistent; or drop JNI from both.

Please ignore this comment too.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From jwaters at openjdk.org  Mon Aug 15 06:49:49 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 06:49:49 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v2]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <CITqHa1NlHj-tAsKa9kGJeYoWBzqPJSPYI3A7f6jpYk=.c99a914e-e438-4151-8665-dfeeeec1da08@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Backout of previous changes, just warn if both are present

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/08b70597..aec9e529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=00-01

  Stats: 85 lines in 2 files changed: 20 ins; 58 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Mon Aug 15 06:51:57 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 06:51:57 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v3]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <9pmQBmQVzaTOxmDQusJrCgTqJnxVRUJJZKm7uBk_5_s=.d8d28d1b-f00d-4e47-adef-b15ac0cb5205@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Whitespaceee

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/aec9e529..a3879c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From aturbanov at openjdk.org  Mon Aug 15 08:23:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Aug 2022 08:23:08 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
Message-ID: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>

It's a bit shorter and clearer.

-------------

Commit messages:
 - [PATCH] Use static methods for hashCode/toString primitives

Changes: https://git.openjdk.org/jdk/pull/9816/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292350
  Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9816/head:pull/9816

PR: https://git.openjdk.org/jdk/pull/9816

From duke at openjdk.org  Mon Aug 15 08:23:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 15 Aug 2022 08:23:09 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <7O38TdppE3N6L3AVwmwskuzGAMYhslZEk6LNPRPvddk=.ee44fa2d-5624-42a4-a757-7c4b74874699@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Also, it?avoids unnecessary?boxing.

-------------

PR: https://git.openjdk.org/jdk/pull/9816

From shade at openjdk.org  Mon Aug 15 11:56:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Aug 2022 11:56:14 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v2]
In-Reply-To: <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>
Message-ID: <sKRj3DJh5DUYNDM8GUyB1jJZNcvfIjDIreDcmUbMO84=.41d93990-1feb-4e58-a76e-7bdc03a8cc74@github.com>

On Mon, 1 Aug 2022 14:50:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Init buf in newStringCp1252

Any thoughts?

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From jwaters at openjdk.org  Mon Aug 15 12:04:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 12:04:23 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v4]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <RKArWUNHXrwWFADiYEIyWsQr2b268fC_VViDeudVDts=.26fe7484-5bc8-49fc-a031-2d46a6025f3d@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a3879c2d..a8dea8a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From aoqi at openjdk.org  Mon Aug 15 12:32:07 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 15 Aug 2022 12:32:07 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms
Message-ID: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>

For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
 

Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
at ImplicitAttach.main(ImplicitAttach.java:48)

-------------

Commit messages:
 - 8292362: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some platforms

Changes: https://git.openjdk.org/jdk/pull/9877/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9877&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292362
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9877.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9877/head:pull/9877

PR: https://git.openjdk.org/jdk/pull/9877

From alanb at openjdk.org  Mon Aug 15 13:02:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 13:02:06 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms
In-Reply-To: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
Message-ID: <d5Df9LfX6YWs2ZJ-KwKk-qDJHZNhq0ClUpt4dV_sBB8=.f14c7da7-a867-4ceb-b163-338ce4b556cc@github.com>

On Mon, 15 Aug 2022 12:23:41 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
>  
> 
> Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
> at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
> at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
> at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
> at ImplicitAttach.main(ImplicitAttach.java:48)

Linker.nativeLinker is currently specified to throw UOE so you might find the following will avoid ports needing to change the test:


--- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/ImplicitAttach.java
+++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/ImplicitAttach.java
@@ -45,7 +45,13 @@ public class ImplicitAttach {
         }
         latch = new CountDownLatch(threadCount);
 
-        Linker abi = Linker.nativeLinker();
+        Linker abi;
+        try {
+            abi = Linker.nativeLinker();
+        } catch (UnsupportedOperationException e) {
+            System.out.println("Test skipped, no native linker on this platform");
+            return;
+        }
 
         // stub to invoke callback
         MethodHandle callback = MethodHandles.lookup()

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From aoqi at openjdk.org  Mon Aug 15 13:23:40 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 15 Aug 2022 13:23:40 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
Message-ID: <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>

> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
>  
> 
> Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
> at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
> at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
> at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
> at ImplicitAttach.main(ImplicitAttach.java:48)

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  Test skipped, when no native linker on this platform

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9877/files
  - new: https://git.openjdk.org/jdk/pull/9877/files/c27d2508..b54d3fd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9877&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9877&range=00-01

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9877.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9877/head:pull/9877

PR: https://git.openjdk.org/jdk/pull/9877

From aoqi at openjdk.org  Mon Aug 15 13:25:12 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 15 Aug 2022 13:25:12 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms
In-Reply-To: <d5Df9LfX6YWs2ZJ-KwKk-qDJHZNhq0ClUpt4dV_sBB8=.f14c7da7-a867-4ceb-b163-338ce4b556cc@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <d5Df9LfX6YWs2ZJ-KwKk-qDJHZNhq0ClUpt4dV_sBB8=.f14c7da7-a867-4ceb-b163-338ce4b556cc@github.com>
Message-ID: <X84siDeajpgvwjfRi_9HU7QPGJgqinpUTYZdk1lomPk=.22939fa9-6728-4d67-abd2-7afba0c1fef3@github.com>

On Mon, 15 Aug 2022 12:59:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Linker.nativeLinker is currently specified to throw UOE so you might find the following will avoid ports needing to change the test less often:
> 
> ```
> --- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/ImplicitAttach.java
> +++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/ImplicitAttach.java
> @@ -45,7 +45,13 @@ public class ImplicitAttach {
>          }
>          latch = new CountDownLatch(threadCount);
>  
> -        Linker abi = Linker.nativeLinker();
> +        Linker abi;
> +        try {
> +            abi = Linker.nativeLinker();
> +        } catch (UnsupportedOperationException e) {
> +            System.out.println("Test skipped, no native linker on this platform");
> +            return;
> +        }
>  
>          // stub to invoke callback
>          MethodHandle callback = MethodHandles.lookup()
> ```

This worked. Thanks, @AlanBateman ! `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1` passed:


Output and diagnostic info for process 9917 was saved into 'pid-9917-output.log'
Test skipped, no native linker on this platform


[2022-08-15T13:17:02.430832622Z] Waiting for completion for process 9917
[2022-08-15T13:17:02.430922220Z] Waiting for completion finished for process 9917
STDERR:

JavaTest Message: Test complete.


TEST RESULT: Passed. Execution successful

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From alanb at openjdk.org  Mon Aug 15 13:25:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 13:25:20 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v2]
In-Reply-To: <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>
Message-ID: <KtulU9-BXLMr8W9cHLVUlrEEYLwZFH_yNPo-C_dU-B8=.30d2b0c0-2e4b-4151-86af-4cf86fb11f80@github.com>

On Mon, 1 Aug 2022 14:50:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Init buf in newStringCp1252

src/java.base/share/native/libjava/jni_util.c line 540:

> 538: {
> 539:     int len = (int) strlen(str);
> 540:     jchar buf[512] = {0};

Also newSizedString8859_1, I would have expected it to complain there too.

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From dholmes at openjdk.org  Mon Aug 15 13:32:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Aug 2022 13:32:24 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
Message-ID: <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>

On Mon, 15 Aug 2022 13:23:40 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
>>  
>> 
>> Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
>> at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
>> at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
>> at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
>> at ImplicitAttach.main(ImplicitAttach.java:48)
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test skipped, when no native linker on this platform

Shouldn't we throw a SkippedException in this case?

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From alanb at openjdk.org  Mon Aug 15 13:32:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 13:32:24 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
 <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>
Message-ID: <kbAjHqFDLB77kU12ornZcSsKHRYLWoiD3pNYw_ZoWfw=.92f8a883-9784-4392-bdb5-b82c457c8ff0@github.com>

On Mon, 15 Aug 2022 13:27:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Shouldn't we throw a SkippedException in this case?

It's the child VM that skips so throwing SkippedException would require special handling in the parent.

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From lancea at openjdk.org  Mon Aug 15 13:35:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 15 Aug 2022 13:35:35 GMT
Subject: RFR: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar [v3]
In-Reply-To: <B3MxWsnHWCk5wLauQphBM38cuU6lDxKxME4SywfpJgo=.a6c30780-4380-4edf-ae4f-1d97aa28b265@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
 <B3MxWsnHWCk5wLauQphBM38cuU6lDxKxME4SywfpJgo=.a6c30780-4380-4edf-ae4f-1d97aa28b265@github.com>
Message-ID: <wRLOhszGQU1qkaLkltpDRqM_Hgbmdp82uBQ9zu-fWUo=.d4506c76-fbd7-46aa-82dd-48f91283722d@github.com>

On Sat, 13 Aug 2022 06:10:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
>> 
>> Find details in https://bugs.openjdk.org/browse/JDK-8292182
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make file name extraction more robust

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From cstein at openjdk.org  Mon Aug 15 13:37:04 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 15 Aug 2022 13:37:04 GMT
Subject: Integrated: 8292182: [TESTLIB] Enhance JAXPPolicyManager to setup
 required permissions for jtreg version 7 jar
In-Reply-To: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
References: <S3NS9yEaUCavCaWG3ay4rmyjpGVdI6pqFN_L6VTPl_I=.16da13c8-1173-4601-bf1a-ea2a163ab509@github.com>
Message-ID: <KwKuEN8kc-eOiOSgALYJWPBwhlN99p_YRQsY-BVdats=.527f7bfe-d7ed-4cb5-a4c2-d0ff094f817a@github.com>

On Fri, 12 Aug 2022 16:26:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Enhance `JAXPPolicyManager` to setup required permissions for `jtreg` 7 by accept version information in JAR file names.
> 
> Find details in https://bugs.openjdk.org/browse/JDK-8292182

This pull request has now been integrated.

Changeset: aa5b7189
Author:    Christian Stein <cstein at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa5b71893307b9fe6137bc3541edccaab73735ac
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8292182: [TESTLIB] Enhance JAXPPolicyManager to setup required permissions for jtreg version 7 jar

Reviewed-by: joehw, lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/9857

From shade at openjdk.org  Mon Aug 15 13:56:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Aug 2022 13:56:38 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
Message-ID: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>

> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
> 
> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
> 
> Additional testing:
>  - [x] Linux x86_32 build with GCC 11
>  - [x]  Linux x86_32 `tier1` test with GCC 9
>  - [x]  Linux x86_64 `tier1` test with GCC 9

Aleksey Shipilev 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:

 - Also improve newSizedString8859_1
 - Merge branch 'master' into JDK-8289049-gcc11-x86-32
 - Init buf in newStringCp1252
 - Another fix
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9702/files
  - new: https://git.openjdk.org/jdk/pull/9702/files/adcbf91c..c2546de4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9702&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9702&range=01-02

  Stats: 15250 lines in 640 files changed: 8464 ins; 4113 del; 2673 mod
  Patch: https://git.openjdk.org/jdk/pull/9702.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9702/head:pull/9702

PR: https://git.openjdk.org/jdk/pull/9702

From shade at openjdk.org  Mon Aug 15 13:56:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Aug 2022 13:56:39 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v2]
In-Reply-To: <KtulU9-BXLMr8W9cHLVUlrEEYLwZFH_yNPo-C_dU-B8=.30d2b0c0-2e4b-4151-86af-4cf86fb11f80@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <xZc7UI0JWWDyBaQFmMbEV3sHWU2KbxetlOk2Gvq4x8Y=.cb069f14-ae6c-496c-b43a-4b6e8f3f770c@github.com>
 <KtulU9-BXLMr8W9cHLVUlrEEYLwZFH_yNPo-C_dU-B8=.30d2b0c0-2e4b-4151-86af-4cf86fb11f80@github.com>
Message-ID: <SodALFHIRoNxW1OVefwe-HDNIBbOSCNUgFqr3J8_h3I=.0906547e-730e-4e76-b9be-9feaf68248bc@github.com>

On Mon, 15 Aug 2022 13:21:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Init buf in newStringCp1252
>
> src/java.base/share/native/libjava/jni_util.c line 540:
> 
>> 538: {
>> 539:     int len = (int) strlen(str);
>> 540:     jchar buf[512] = {0};
> 
> Also newSizedString8859_1, I would have expected it to complain there too.

I think the compilers complain about `malloc`-ed paths, but we can harmonize `newSizedString8859_1` too. Please see new commit.

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From aoqi at openjdk.org  Mon Aug 15 13:59:16 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 15 Aug 2022 13:59:16 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <kbAjHqFDLB77kU12ornZcSsKHRYLWoiD3pNYw_ZoWfw=.92f8a883-9784-4392-bdb5-b82c457c8ff0@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
 <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>
 <kbAjHqFDLB77kU12ornZcSsKHRYLWoiD3pNYw_ZoWfw=.92f8a883-9784-4392-bdb5-b82c457c8ff0@github.com>
Message-ID: <pwkOEC4A3vDbp7Z6rhTWRLpkrt2vz160HxpL7iZ6OzA=.b7102ec9-dd69-4283-a31e-6d59eb13926b@github.com>

On Mon, 15 Aug 2022 13:30:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Shouldn't we throw a SkippedException in this case?
> 
> It's the child VM that skips so throwing SkippedException would require special handling in the parent.

Like this?

diff --git a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
index b93e7918014..156bbe35c62 100644
--- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
+++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
@@ -48,6 +48,8 @@ import java.util.stream.Stream;
 import jdk.test.lib.process.ProcessTools;
 import jdk.test.lib.process.OutputAnalyzer;
 
+import jtreg.SkippedException;
+
 public class AttachTest {
     static final String TEST_CLASSES = System.getProperty("test.classes");
     static final String JAVA_LIBRARY_PATH = System.getProperty("java.library.path");
@@ -63,6 +65,9 @@ public class AttachTest {
                 .executeTestJava(opts)
                 .outputTo(System.out)
                 .errorTo(System.out);
+        if (outputAnalyzer.getOutput().contains("Test skipped, no native linker on this platform")) {
+            throw new SkippedException("Test skipped, no native linker on this platform");
+        }
         outputAnalyzer.shouldHaveExitValue(0);
     }
 }

Do I need to add this change?

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From rriggs at openjdk.org  Mon Aug 15 14:39:18 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Aug 2022 14:39:18 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
In-Reply-To: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
Message-ID: <KNwp5VuBH0YyqtVlRsdRkOM9rcgb1_ppIjoeeXJ-jOU=.4098b6ed-0ae0-4ac4-bfa5-7f920055bad7@github.com>

On Wed, 3 Aug 2022 16:28:31 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.

test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedCount.java line 30:

> 28: import org.openjdk.jmh.annotations.Measurement;
> 29: import org.openjdk.jmh.annotations.Fork;
> 30: import org.openjdk.jmh.annotations.Measurement;

Should there have been annotations for Fork to go with this import?
Importing Measurement again is a dup.

test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedSum.java line 33:

> 31: import org.openjdk.jmh.annotations.Mode;
> 32: import org.openjdk.jmh.annotations.OutputTimeUnit;
> 33: import org.openjdk.jmh.annotations.Param;

Ditto imports vs annotations.

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From rriggs at openjdk.org  Mon Aug 15 14:39:34 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Aug 2022 14:39:34 GMT
Subject: RFR: 8292196: Reduce runtime of java.util.regex microbenchmarks
In-Reply-To: <UarXS4dg6UO7RMbaCCQ13blAG1vxCFr9F-bB7nfST68=.ada2085f-0aa3-4573-a60d-4aeabb489e2e@github.com>
References: <UarXS4dg6UO7RMbaCCQ13blAG1vxCFr9F-bB7nfST68=.ada2085f-0aa3-4573-a60d-4aeabb489e2e@github.com>
Message-ID: <Wv-T33BaIAsmQ0jkRv_5dDUpJzhjY1J9-a2Wd_sD74k=.51f1e681-b135-45a9-9d5a-3a352c0f2ec3@github.com>

On Fri, 12 Aug 2022 18:20:04 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the run time to 45 minutes from about 1h40m with stability good enough for weekly promo build testing.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9861

From alanb at openjdk.org  Mon Aug 15 14:51:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 14:51:13 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <pwkOEC4A3vDbp7Z6rhTWRLpkrt2vz160HxpL7iZ6OzA=.b7102ec9-dd69-4283-a31e-6d59eb13926b@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
 <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>
 <kbAjHqFDLB77kU12ornZcSsKHRYLWoiD3pNYw_ZoWfw=.92f8a883-9784-4392-bdb5-b82c457c8ff0@github.com>
 <pwkOEC4A3vDbp7Z6rhTWRLpkrt2vz160HxpL7iZ6OzA=.b7102ec9-dd69-4283-a31e-6d59eb13926b@github.com>
Message-ID: <-Lq6tBKTZv8vMp7wwWZyWkjcaKZuSvQWzN8SZavygFM=.7a4ec78b-feca-4987-bf1e-88d0b8fb8897@github.com>

On Mon, 15 Aug 2022 13:57:02 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> > > Shouldn't we throw a SkippedException in this case?
> > 
> > 
> > It's the child VM that skips so throwing SkippedException would require special handling in the parent.
> 
> Like this?
> 
> ```
> diff --git a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
> index b93e7918014..156bbe35c62 100644
> --- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
> +++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
> @@ -48,6 +48,8 @@ import java.util.stream.Stream;
>  import jdk.test.lib.process.ProcessTools;
>  import jdk.test.lib.process.OutputAnalyzer;
>  
> +import jtreg.SkippedException;
> +
>  public class AttachTest {
>      static final String TEST_CLASSES = System.getProperty("test.classes");
>      static final String JAVA_LIBRARY_PATH = System.getProperty("java.library.path");
> @@ -63,6 +65,9 @@ public class AttachTest {
>                  .executeTestJava(opts)
>                  .outputTo(System.out)
>                  .errorTo(System.out);
> +        if (outputAnalyzer.getOutput().contains("Test skipped, no native linker on this platform")) {
> +            throw new SkippedException("Test skipped, no native linker on this platform");
> +        }
>          outputAnalyzer.shouldHaveExitValue(0);
>      }
>  }
> ```
> 
> Do I need to add this change?

That would work too but I think what you have in the PR now is okay.

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From alanb at openjdk.org  Mon Aug 15 15:31:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 15:31:36 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
Message-ID: <2ZqSsfhYprVTcbzmLq2ycSI0DyCNqgSL5hDMEGx1hYs=.ab6370ff-461f-44a4-a0c6-ac8b501b1cbf@github.com>

On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev 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:
> 
>  - Also improve newSizedString8859_1
>  - Merge branch 'master' into JDK-8289049-gcc11-x86-32
>  - Init buf in newStringCp1252
>  - Another fix
>  - Fix

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From psandoz at openjdk.org  Mon Aug 15 15:43:30 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 15 Aug 2022 15:43:30 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <YpycKW6nf5iKoi-NaYZ7x8MIi5GIIS86sPCdhmvGlP0=.0255a51c-52de-42c6-8671-114da5dd3cab@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <YpycKW6nf5iKoi-NaYZ7x8MIi5GIIS86sPCdhmvGlP0=.0255a51c-52de-42c6-8671-114da5dd3cab@github.com>
Message-ID: <DfNgyit7I4HD-ml7RNz6oJnK5vnK-H4dD0uAfdxJyyY=.7d4e123c-fb55-42dc-ac64-942e3496ee0e@github.com>

On Mon, 15 Aug 2022 01:10:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
>> 
>> 
>> 1) mask = a.compare(0, ne);
>> 2) b = b.blend(0, mask);
>> 3) result = a | b;
>> 
>> 
>> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
>> 
>> A simpler implementation is:
>> 
>> 
>> 1) mask = a.compare(0, eq);
>> 2) result = a.blend(b, mask);
>> 
>> 
>> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
>> 
>> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
>> 
>> Benchmark                          (size) Mode  Cnt  Before    After    Units
>> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
>> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
>> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
>> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
>> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
>> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
>> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
>> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
>> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
>> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
>> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
>> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
>> 
>> We can also observe the similar improvement on x86 system.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266
>
> ping again. Could anyone please take a look at this simple patch? Thanks so much for your time!

@XiaohongGong looking... (just back from vacation).

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From alanb at openjdk.org  Mon Aug 15 16:12:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 16:12:33 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v2]
In-Reply-To: <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>
Message-ID: <ctBTicLgxhqurk8jRZOs4ytEcdUDCHyijUVNFJX4y90=.a2c7a35e-8eab-4782-9842-5d6e4c2a9ff4@github.com>

On Thu, 11 Aug 2022 14:16:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
>> 
>> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>> 
>> A new test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments and add more testing

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2630:

> 2628:         int h = 0;
> 2629:         for (Enum<?> e : enums) {
> 2630:             h += e.name().hashCode();

Good

test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 83:

> 81:         final Set<ModuleDescriptor.Opens.Modifier> mods2 = Set.of(
> 82:                 ModuleDescriptor.Opens.Modifier.MANDATED, ModuleDescriptor.Opens.Modifier.SYNTHETIC);
> 83:         final ModuleDescriptor desc2 = createModuleDescriptor(mods2, null, null);

If you import Requires, Exports and Opens then it should mean you can fit these onto a single line and might be easier to read, e.g.

var mods2 = Set.of(Opens.Modifier.MANDATED, Opens.Modifier.SYNTHETIC);

test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 181:

> 179:             Set<ModuleDescriptor.Exports.Modifier> expsModifiers) {
> 180: 
> 181:         final var mdb = ModuleDescriptor.newModule("foobar");

Does "mdb" stand for something here?

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From psandoz at openjdk.org  Mon Aug 15 16:21:20 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 15 Aug 2022 16:21:20 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

Looks good. Much better to flip the operation and the receiver + first arg to the blend.

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From alanb at openjdk.org  Mon Aug 15 16:43:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 16:43:24 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <SXnF3WP6C49i9tcKothO59uLTAjBPvaU309LCKjf9n8=.444924c8-5338-4eb1-9e33-3a3a4e4e6f0b@github.com>

On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

This is hard to review. Would it be possible to provide a summary on the APIs and df behave with quotas?

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From prr at openjdk.org  Mon Aug 15 16:45:13 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 15 Aug 2022 16:45:13 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <HLpZp-J-gPnYyisAFC2o37e6OI3JaYya9E8N9bOO8Uw=.92d03070-6dcc-4417-b253-8d30bcfe6186@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Approving (just) the client change

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9816

From ecaspole at openjdk.org  Mon Aug 15 16:57:36 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Mon, 15 Aug 2022 16:57:36 GMT
Subject: Integrated: 8292196: Reduce runtime of java.util.regex microbenchmarks
In-Reply-To: <UarXS4dg6UO7RMbaCCQ13blAG1vxCFr9F-bB7nfST68=.ada2085f-0aa3-4573-a60d-4aeabb489e2e@github.com>
References: <UarXS4dg6UO7RMbaCCQ13blAG1vxCFr9F-bB7nfST68=.ada2085f-0aa3-4573-a60d-4aeabb489e2e@github.com>
Message-ID: <Kpbwzomgh1BN5_VKCCfZYLsG1Rned4eD4Fk9F8HQFiI=.944f7170-7de7-4fbc-b465-9f02259af178@github.com>

On Fri, 12 Aug 2022 18:20:04 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the run time to 45 minutes from about 1h40m with stability good enough for weekly promo build testing.

This pull request has now been integrated.

Changeset: b5707b03
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5707b0376660cd8763e46d525ba614b08a59d7b
Stats:     27 lines in 4 files changed: 4 ins; 14 del; 9 mod

8292196: Reduce runtime of java.util.regex microbenchmarks

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9861

From bpb at openjdk.org  Mon Aug 15 17:28:11 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Aug 2022 17:28:11 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
In-Reply-To: <SXnF3WP6C49i9tcKothO59uLTAjBPvaU309LCKjf9n8=.444924c8-5338-4eb1-9e33-3a3a4e4e6f0b@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
 <SXnF3WP6C49i9tcKothO59uLTAjBPvaU309LCKjf9n8=.444924c8-5338-4eb1-9e33-3a3a4e4e6f0b@github.com>
Message-ID: <knYObbZUoGTPhT3cpX7WBQM6lLkvm-ANJ59fYHi1OeY=.81c77776-ad3a-4f5f-be4a-d7380343fa79@github.com>

On Mon, 15 Aug 2022 16:39:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is hard to review. Would it be possible to provide a summary on the APIs and df behave with quotas?

We use the Windows API [GetDiskFreeSpaceEx](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskfreespaceexw) wherein it is stated
- lpFreeBytesAvailableToCaller: If per-user quotas are being used, this value may be less than the total number of free bytes on a disk.
- lpTotalNumberOfBytes: If per-user quotas are being used, this value may be less than the total number of bytes on a disk.

The `df` command on the other hand appears to be using something like [GetQuotaInformation](https://docs.microsoft.com/en-us/windows/win32/api/dskquota/nf-dskquota-idiskquotauser-getquotainformation) which fills a [structure](https://docs.microsoft.com/en-us/windows/win32/api/dskquota/ns-dskquota-diskquota_user_information) which accounts for the quota and provides the currently used and maximum allowed number of bytes for a user.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From bpb at openjdk.org  Mon Aug 15 17:33:12 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Aug 2022 17:33:12 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160"
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <vtdrEo7qjrf2shNNxJeqbRY-fVSHRunhKvCRW9W-VPQ=.70952fd9-10b9-4163-ba8c-0d7810f26af1@github.com>

On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

In reality GetFreeDiskSpaceEx does not appear to recognize the quotas, at least in our tests.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From jwaters at openjdk.org  Mon Aug 15 17:54:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 17:54:20 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v5]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <myxoB4M_piuUAxVtNGJ1SdYbAIOk52mJYaoCs1jN_uA=.e0786cd0-d417-484e-bd03-17f3207d4312@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert accidental removal of memory release

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a8dea8a2..04909015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From simonis at openjdk.org  Mon Aug 15 17:59:23 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 Aug 2022 17:59:23 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
Message-ID: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>

The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 

The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:

> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."

-------------

Commit messages:
 - 8292327: java.io.EOFException in InflaterInputStream after JDK-8281962

Changes: https://git.openjdk.org/jdk/pull/9881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292327
  Stats: 78 lines in 3 files changed: 77 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9881.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9881/head:pull/9881

PR: https://git.openjdk.org/jdk/pull/9881

From jwaters at openjdk.org  Mon Aug 15 18:09:36 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 18:09:36 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v6]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <umWNXfUkWddsS8zI8ZpfYTVrm65LcRZMJvili7CIly0=.1a1aa7e5-2ba6-499c-aec0-6486a482571d@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Refactor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/04909015..82419b64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From alanb at openjdk.org  Mon Aug 15 18:41:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 18:41:39 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
In-Reply-To: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
Message-ID: <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>

On Mon, 15 Aug 2022 17:43:27 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
> 
> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
> 
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 158:

> 156:                     return -1;
> 157:                 }
> 158:                 if (inf.needsInput() && !inf.hasPendingOutput()) {

I think the approach looks okay and avoids attempting to fill and the unspecified EOFException that it throws when the input is at EOF.

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 161:

> 159:                     // Even if needsInput() is true, the native inflater may have some
> 160:                     // buffered data which couldn't fit in to the output buffer during the
> 161:                     // last call to inflate. Consume that bffered data first before calling

bffered -> buffered

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 164:

> 162:                     // fill() to avoid an EOF error if no more input is available and the
> 163:                     // next call to inflate will finish the inflation.
> 164:                     fill();

We need to submit a bug against fill() too as it is not currently specified to throw when the input is at EOF.

test/jdk/java/util/zip/InflaterInputStream/EOF.java line 37:

> 35: import java.util.zip.InflaterInputStream;
> 36: 
> 37: public class EOF {

This is not a general purpose test for EOF so I think we'll need to find a better name.  BufferedBytesAtInputEOF might work.

Also the test doesn't check the output. We'll need to do that to make it a more complete test.

test/jdk/java/util/zip/InflaterInputStream/EOF.java line 61:

> 59:       n = is.read(buf, 0, 1); // Unexpected end of ZLIB input stream
> 60:     }
> 61:   }

Can you re-format this to use 4 space indent?

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From jwaters at openjdk.org  Mon Aug 15 18:47:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 18:47:29 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <LZQ4WRW5n0vVzIIYAQ99w9eJc6_sLCu7CB5_fojLgHQ=.d1ce8375-30fd-43fd-bee1-f6047ceaaa84@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  errno should be checked for a 0 status code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/82419b64..d4204bfa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=05-06

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From ecaspole at openjdk.org  Mon Aug 15 18:53:14 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Mon, 15 Aug 2022 18:53:14 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
In-Reply-To: <KNwp5VuBH0YyqtVlRsdRkOM9rcgb1_ppIjoeeXJ-jOU=.4098b6ed-0ae0-4ac4-bfa5-7f920055bad7@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
 <KNwp5VuBH0YyqtVlRsdRkOM9rcgb1_ppIjoeeXJ-jOU=.4098b6ed-0ae0-4ac4-bfa5-7f920055bad7@github.com>
Message-ID: <zg_a2XHWB__rRCVWF8B1Fgaoo2fxu5P9C7NQyFzzeKM=.6f6ffaa2-ae8e-405b-80ca-a0e624572501@github.com>

On Mon, 15 Aug 2022 14:32:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.
>
> test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedCount.java line 30:
> 
>> 28: import org.openjdk.jmh.annotations.Measurement;
>> 29: import org.openjdk.jmh.annotations.Fork;
>> 30: import org.openjdk.jmh.annotations.Measurement;
> 
> Should there have been annotations for Fork to go with this import?
> Importing Measurement again is a dup.

Good eye, this one has some mistake, I will fix these and get a new time estimate overnight.

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From jwaters at openjdk.org  Mon Aug 15 19:00:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Aug 2022 19:00:24 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <_V16sQnxJQ6HfU8irijvGeUY8WVJuToCEC30rSs525o=.b43585dd-7174-4994-b56d-f6d5bf27fb66@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Tabs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/d4204bfa..a1fc9cd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From rriggs at openjdk.org  Mon Aug 15 19:04:10 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Aug 2022 19:04:10 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <z6Zu0EJkgkAEEo3SdyI3L9Ugrh0n5u_ePzYzp2GtXHw=.817d4c98-15b5-4ad0-8673-63c362735f5e@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9816

From simonis at openjdk.org  Mon Aug 15 19:40:17 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 Aug 2022 19:40:17 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
In-Reply-To: <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
Message-ID: <XuSKlAy7zkbzleVqUBNiz5MsxuRPg3PxA_PFUfFn5gQ=.0cfab52f-a5d8-4820-b898-4e02c0897fb3@github.com>

On Mon, 15 Aug 2022 18:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> test/jdk/java/util/zip/InflaterInputStream/EOF.java line 61:
> 
>> 59:       n = is.read(buf, 0, 1); // Unexpected end of ZLIB input stream
>> 60:     }
>> 61:   }
> 
> Can you re-format this to use 4 space indent?

Done

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From simonis at openjdk.org  Mon Aug 15 19:47:27 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 Aug 2022 19:47:27 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
In-Reply-To: <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
Message-ID: <-nttFBtCW-DSuA3WUTp9TAlI684Ko4QtyiscLQlsQZ0=.508bc998-300d-4566-b109-025ce0009bce@github.com>

On Mon, 15 Aug 2022 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 161:
> 
>> 159:                     // Even if needsInput() is true, the native inflater may have some
>> 160:                     // buffered data which couldn't fit in to the output buffer during the
>> 161:                     // last call to inflate. Consume that bffered data first before calling
> 
> bffered -> buffered

Fixed.

> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 164:
> 
>> 162:                     // fill() to avoid an EOF error if no more input is available and the
>> 163:                     // next call to inflate will finish the inflation.
>> 164:                     fill();
> 
> We need to submit a bug against fill() too as it is not currently specified to throw when the input is at EOF.

Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "*if an I/O error has occurred*" description in the throws section.

Do you propose to be more specific there and write something like "*if an I/O error has occurred or the end of the input buffer has been reached*"?

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From simonis at openjdk.org  Mon Aug 15 20:19:18 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 Aug 2022 20:19:18 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
In-Reply-To: <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
Message-ID: <3ivCblxO_I-EZE1FZGAzkXvBYe226EFbyxqr50TF0co=.94471bb5-febb-4a4b-afb5-737a5a6d98db@github.com>

On Mon, 15 Aug 2022 18:36:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> test/jdk/java/util/zip/InflaterInputStream/EOF.java line 37:
> 
>> 35: import java.util.zip.InflaterInputStream;
>> 36: 
>> 37: public class EOF {
> 
> This is not a general purpose test for EOF so I think we'll need to find a better name.  BufferedBytesAtInputEOF might work.
> 
> Also the test doesn't check the output. We'll need to do that to make it a more complete test.

Changed the name to `UnexpectedEndOfZlibStream.java` and updated the test as requested.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From simonis at openjdk.org  Mon Aug 15 20:23:16 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 Aug 2022 20:23:16 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
Message-ID: <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>

> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
> 
> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
> 
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes regarding indentation, naming and spelling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9881/files
  - new: https://git.openjdk.org/jdk/pull/9881/files/74eb08c2..3bbfacf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9881&range=00-01

  Stats: 136 lines in 3 files changed: 73 ins; 62 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9881.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9881/head:pull/9881

PR: https://git.openjdk.org/jdk/pull/9881

From jpai at openjdk.org  Tue Aug 16 01:47:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Aug 2022 01:47:09 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v2]
In-Reply-To: <ctBTicLgxhqurk8jRZOs4ytEcdUDCHyijUVNFJX4y90=.a2c7a35e-8eab-4782-9842-5d6e4c2a9ff4@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>
 <ctBTicLgxhqurk8jRZOs4ytEcdUDCHyijUVNFJX4y90=.a2c7a35e-8eab-4782-9842-5d6e4c2a9ff4@github.com>
Message-ID: <bM5mey0PGLJygOqIj9fNqOUjHomvAF_ooivq4OBJtI8=.e9c4b4c4-031e-4365-9944-bb420bf4239a@github.com>

On Mon, 15 Aug 2022 16:07:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   incorporate review comments and add more testing
>
> test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 181:
> 
>> 179:             Set<ModuleDescriptor.Exports.Modifier> expsModifiers) {
>> 180: 
>> 181:         final var mdb = ModuleDescriptor.newModule("foobar");
> 
> What does "mdb" stand for here?

Hello Alan, that was supposed to mean module descriptor builder. I will rename it to `builder` to be clear.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From jpai at openjdk.org  Tue Aug 16 02:08:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Aug 2022 02:08:43 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v3]
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <4W_W4rNHI-HztCVU6c-tMvqsgNigSI_1Q6uTj6YgQJU=.2159c7ce-46b6-49ea-9fbf-789c6a421878@github.com>

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Review comments - variable name and imports organization in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9790/files
  - new: https://git.openjdk.org/jdk/pull/9790/files/4933e6d6..114c1aa7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9790&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9790&range=01-02

  Stats: 23 lines in 1 file changed: 3 ins; 6 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9790/head:pull/9790

PR: https://git.openjdk.org/jdk/pull/9790

From jpai at openjdk.org  Tue Aug 16 02:08:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Aug 2022 02:08:44 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v2]
In-Reply-To: <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <2k0TknbGuQYBOECOd50KbwTrUTLpDmhqfKnDuCJcirI=.4e0b2ed7-9a42-4827-96c0-9e323e4e645d@github.com>
Message-ID: <pxywdEqDBKKAvWYD20kK3ApYkdbX1oOQLuvXYLCAFTg=.3f578ac7-e05d-44f5-9b19-fd03f49c337a@github.com>

On Thu, 11 Aug 2022 14:16:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
>> 
>> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>> 
>> A new test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments and add more testing

I've now updated the PR to rename `mdb` to `builder` and add relevant imports to reduce line lengths where those enums were referenced.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From alanb at openjdk.org  Tue Aug 16 06:16:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 06:16:22 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v3]
In-Reply-To: <4W_W4rNHI-HztCVU6c-tMvqsgNigSI_1Q6uTj6YgQJU=.2159c7ce-46b6-49ea-9fbf-789c6a421878@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <4W_W4rNHI-HztCVU6c-tMvqsgNigSI_1Q6uTj6YgQJU=.2159c7ce-46b6-49ea-9fbf-789c6a421878@github.com>
Message-ID: <EJylumw5PCF_-NUwnYbnL5PtXgpSG8Kn4iBE7gRdV2w=.7a63df6e-601a-4334-bfde-b9b65130ca56@github.com>

On Tue, 16 Aug 2022 02:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
>> 
>> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>> 
>> A new test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - variable name and imports organization in test

Thanks for the updates, I think it looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9790

From alanb at openjdk.org  Tue Aug 16 06:18:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 06:18:24 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
Message-ID: <-wSEspYo-NZvi2dDStmrmFGtRplYYB2ajMAAyqcYmyk=.fbdec066-798e-44c9-9555-8b9593eaeebe@github.com>

On Mon, 15 Aug 2022 13:23:40 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
>>  
>> 
>> Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
>> at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
>> at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
>> at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
>> at ImplicitAttach.main(ImplicitAttach.java:48)
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test skipped, when no native linker on this platform

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From alanb at openjdk.org  Tue Aug 16 06:20:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 06:20:24 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
Message-ID: <nBEtRpLNvcYbMsE25wc73nUpDZWOItUsZABZrBXvWG0=.7959213e-b4d8-4680-94cc-eebef140fd74@github.com>

On Mon, 15 Aug 2022 20:23:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes regarding indentation, naming and spelling

> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) 

In the description, this should link to JDK-8281962 rather than (JDK-8292327). Just pointing out as someone looking at this PR in the future might get confused as to which issue caused the regression.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From alanb at openjdk.org  Tue Aug 16 06:30:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 06:30:16 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <-nttFBtCW-DSuA3WUTp9TAlI684Ko4QtyiscLQlsQZ0=.508bc998-300d-4566-b109-025ce0009bce@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
 <-nttFBtCW-DSuA3WUTp9TAlI684Ko4QtyiscLQlsQZ0=.508bc998-300d-4566-b109-025ce0009bce@github.com>
Message-ID: <tl8OTNpuzLvQ7Oot0rEzYMxq7x3IMPmAXFwkfDG17T4=.467be34c-52e2-4cdd-83ac-3b3ad3c16e1e@github.com>

On Mon, 15 Aug 2022 19:42:36 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 164:
>> 
>>> 162:                     // fill() to avoid an EOF error if no more input is available and the
>>> 163:                     // next call to inflate will finish the inflation.
>>> 164:                     fill();
>> 
>> We need to submit a bug against fill() too as it is not currently specified to throw when the input is at EOF.
>
> Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "*if an I/O error has occurred*" description in the throws section.
> 
> Do you propose to be more specific there and write something like "*if an I/O error has occurred or the end of the input buffer has been reached*"?

> Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "_if an I/O error has occurred_" description in the throws section.
> 
> Do you propose to be more specific there and write something like "_if an I/O error has occurred or the end of the input buffer has been reached_"?

Like many JDK 1.1 era APIs, InflaterInputStream is very under-specified. In this case, the protected fill method is begging us to specify how it behaves when the input is at EOF. An I/O error is surprising here as it sets the protected len field to indicate EOF. We can't change it after 25 years so we will need to specify existing behavior.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From aoqi at openjdk.org  Tue Aug 16 07:28:34 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 16 Aug 2022 07:28:34 GMT
Subject: RFR: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms [v2]
In-Reply-To: <-Lq6tBKTZv8vMp7wwWZyWkjcaKZuSvQWzN8SZavygFM=.7a4ec78b-feca-4987-bf1e-88d0b8fb8897@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
 <lfg0b8JG_UHprgPxCKzBZOxYDjXOQJb0qVRR6UwiJWo=.de05152b-54f2-420a-883c-2b1c7ffdf621@github.com>
 <TCmdYu6MEuE80Z71HFegV8fwA2vtbeCoc7BzMv9E3N0=.a1adf278-acd7-46ab-ab24-4dd5c5114b89@github.com>
 <kbAjHqFDLB77kU12ornZcSsKHRYLWoiD3pNYw_ZoWfw=.92f8a883-9784-4392-bdb5-b82c457c8ff0@github.com>
 <pwkOEC4A3vDbp7Z6rhTWRLpkrt2vz160HxpL7iZ6OzA=.b7102ec9-dd69-4283-a31e-6d59eb13926b@github.com>
 <-Lq6tBKTZv8vMp7wwWZyWkjcaKZuSvQWzN8SZavygFM=.7a4ec78b-feca-4987-bf1e-88d0b8fb8897@github.com>
Message-ID: <9PSoDZ5Rgebh9s0RpGHrLlmOVnErR_WidTCQU6tRryA=.ebe94b08-7077-425d-996e-fce695eceb6a@github.com>

On Mon, 15 Aug 2022 14:49:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Shouldn't we throw a SkippedException in this case?
>>> 
>>> It's the child VM that skips so throwing SkippedException would require special handling in the parent.
>> 
>> Like this?
>> 
>> diff --git a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> index b93e7918014..156bbe35c62 100644
>> --- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> +++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> @@ -48,6 +48,8 @@ import java.util.stream.Stream;
>>  import jdk.test.lib.process.ProcessTools;
>>  import jdk.test.lib.process.OutputAnalyzer;
>>  
>> +import jtreg.SkippedException;
>> +
>>  public class AttachTest {
>>      static final String TEST_CLASSES = System.getProperty("test.classes");
>>      static final String JAVA_LIBRARY_PATH = System.getProperty("java.library.path");
>> @@ -63,6 +65,9 @@ public class AttachTest {
>>                  .executeTestJava(opts)
>>                  .outputTo(System.out)
>>                  .errorTo(System.out);
>> +        if (outputAnalyzer.getOutput().contains("Test skipped, no native linker on this platform")) {
>> +            throw new SkippedException("Test skipped, no native linker on this platform");
>> +        }
>>          outputAnalyzer.shouldHaveExitValue(0);
>>      }
>>  }
>> 
>> Do I need to add this change?
>
>> > > Shouldn't we throw a SkippedException in this case?
>> > 
>> > 
>> > It's the child VM that skips so throwing SkippedException would require special handling in the parent.
>> 
>> Like this?
>> 
>> ```
>> diff --git a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> index b93e7918014..156bbe35c62 100644
>> --- a/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> +++ b/test/jdk/java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
>> @@ -48,6 +48,8 @@ import java.util.stream.Stream;
>>  import jdk.test.lib.process.ProcessTools;
>>  import jdk.test.lib.process.OutputAnalyzer;
>>  
>> +import jtreg.SkippedException;
>> +
>>  public class AttachTest {
>>      static final String TEST_CLASSES = System.getProperty("test.classes");
>>      static final String JAVA_LIBRARY_PATH = System.getProperty("java.library.path");
>> @@ -63,6 +65,9 @@ public class AttachTest {
>>                  .executeTestJava(opts)
>>                  .outputTo(System.out)
>>                  .errorTo(System.out);
>> +        if (outputAnalyzer.getOutput().contains("Test skipped, no native linker on this platform")) {
>> +            throw new SkippedException("Test skipped, no native linker on this platform");
>> +        }
>>          outputAnalyzer.shouldHaveExitValue(0);
>>      }
>>  }
>> ```
>> 
>> Do I need to add this change?
> 
> That would work too but I think what you have in the PR now is okay.

Thanks to @AlanBateman  for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From shade at openjdk.org  Tue Aug 16 07:44:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Aug 2022 07:44:08 GMT
Subject: RFR: 8292352: 32-bit Windows build failures after JDK-8290059
In-Reply-To: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
References: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
Message-ID: <K_S8ebyiLPS15Zxbv8nTszVopyGjIo2BU-YxH9EyBk4=.e3443200-4206-496c-b491-5b479ee8df97@github.com>

On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The affected file was added by [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled for tests. Looks like we really need the "WINAPI" macro in the definition, so that we match the stdcall. See the example declaration in the [docs](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85)).
> 
> Attn @JornVernee.
> 
> Additional testing:
>  - [x] Windows x86_32 builds/test now pass
>  - [ ]  Windows x86_64 builds/test still pass

Ah, labels. Let's pretend this is the same as [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059).

-------------

PR: https://git.openjdk.org/jdk/pull/9875

From shade at openjdk.org  Tue Aug 16 07:44:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Aug 2022 07:44:06 GMT
Subject: RFR: 8292352: 32-bit Windows build failures after JDK-8290059
Message-ID: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>

The affected file was added by [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled for tests. Looks like we really need the "WINAPI" macro in the definition, so that we match the stdcall. See the example declaration in the [docs](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85)).

Attn @JornVernee.

Additional testing:
 - [x] Windows x86_32 builds/test now pass
 - [ ]  Windows x86_64 builds/test still pass

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/9875/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9875&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292352
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9875.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9875/head:pull/9875

PR: https://git.openjdk.org/jdk/pull/9875

From stuefe at openjdk.org  Tue Aug 16 08:14:12 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Aug 2022 08:14:12 GMT
Subject: RFR: 8292352: 32-bit Windows build failures after JDK-8290059
In-Reply-To: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
References: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
Message-ID: <shTbmQkIZqfJD8CdRnHiKbxAWdJfitrc3znf30j20gQ=.587cf8ce-fbca-4f29-a85b-e04a376278a0@github.com>

On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The affected file was added by [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled for tests. Looks like we really need the "WINAPI" macro in the definition, so that we match the stdcall. See the example declaration in the [docs](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85)).
> 
> Attn @JornVernee.
> 
> Additional testing:
>  - [x] Windows x86_32 builds/test now pass
>  - [ ]  Windows x86_64 builds/test still pass

Looks good and trivial. This came up during the original PR discussion but we thought it would not be needed.

Cheers, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9875

From shade at openjdk.org  Tue Aug 16 08:31:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Aug 2022 08:31:11 GMT
Subject: RFR: 8292407: Improve Weak* VarHandle tests resilience under spurious
 failures
Message-ID: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>

We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.

The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.

The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292407
  Stats: 297 lines in 26 files changed: 296 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From jpai at openjdk.org  Tue Aug 16 08:35:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Aug 2022 08:35:09 GMT
Subject: RFR: 8290041: ModuleDescriptor.hashCode is inconsistent [v3]
In-Reply-To: <4W_W4rNHI-HztCVU6c-tMvqsgNigSI_1Q6uTj6YgQJU=.2159c7ce-46b6-49ea-9fbf-789c6a421878@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
 <4W_W4rNHI-HztCVU6c-tMvqsgNigSI_1Q6uTj6YgQJU=.2159c7ce-46b6-49ea-9fbf-789c6a421878@github.com>
Message-ID: <LnGAfzPKJm8OXrpb4kmz-PVSyFgsy2XHqHWqgSIgT8Q=.cee168cf-efc4-4a14-bd25-37564c570282@github.com>

On Tue, 16 Aug 2022 02:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
>> 
>> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
>> 
>> A new test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - variable name and imports organization in test

Thank you Alan and Peter for the reviews. tier1, tier2 and tier3 testing passed with these changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From jpai at openjdk.org  Tue Aug 16 08:35:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Aug 2022 08:35:11 GMT
Subject: Integrated: 8290041: ModuleDescriptor.hashCode is inconsistent
In-Reply-To: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
References: <nQg1qbtXeVlXU0jZIqhU6SBV-VwXokgMQ1DgW4j5G24=.527db8b1-b9ff-43ca-a398-5f1d87680a2c@github.com>
Message-ID: <AIqbXpFKNeoFU7mVsb-5dSIRrNKnC6_H38vCS70LqGs=.f2a71b52-536c-4ca5-9161-447a165c4cee@github.com>

On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8290041? 
> 
> As noted by the reporter, the current implementation is buggy since the calculation can result in a different value of the hashcode depending on the order of iteration of the `Modifier`s. The commit in this PR changes that computation to produce consistent result irrespective of the order in which the `Modifier`s (enum) is iterated upon.
> 
> A new test has been added which reproduces the issue and verifies the fix.

This pull request has now been integrated.

Changeset: 4cc6cb9d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cc6cb9d9ddbcc540baac7b81398f2af83f93340
Stats:     123 lines in 2 files changed: 117 ins; 3 del; 3 mod

8290041: ModuleDescriptor.hashCode is inconsistent

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9790

From plevart at openjdk.org  Tue Aug 16 09:10:28 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 16 Aug 2022 09:10:28 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
In-Reply-To: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
Message-ID: <_9jRaj6gXaBHpNnmSqibSGRDejSvzj2mu9XcZJybbd8=.6e694073-5fa6-43e1-ab46-a18e6c3c0bcd@github.com>

On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 84:

> 82:             testCase(42, ttl -> { ttl.set(NULL); ttl.remove(); ttl.get();     }, 42  ),
> 83:             testCase(42, ttl -> { ttl.get();     ttl.remove(); ttl.set(NULL); }, NULL),
> 84:         };

Hm, what about expanding the test cases programmatically. Like this?
https://github.com/plevart/jdk/commit/ffc681f3cccfdf473d4cc037e5f3e50f8172eec3
...it's easier to follow. Some nits included...

-------------

PR: https://git.openjdk.org/jdk/pull/9819

From simonis at openjdk.org  Tue Aug 16 09:13:21 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 09:13:21 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <tl8OTNpuzLvQ7Oot0rEzYMxq7x3IMPmAXFwkfDG17T4=.467be34c-52e2-4cdd-83ac-3b3ad3c16e1e@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <X17jGL0eRspnLXCFKwlOypQoLttahulJbnjFO-ZqxHs=.7d0df787-5309-4563-bcd4-92a55e9a3685@github.com>
 <-nttFBtCW-DSuA3WUTp9TAlI684Ko4QtyiscLQlsQZ0=.508bc998-300d-4566-b109-025ce0009bce@github.com>
 <tl8OTNpuzLvQ7Oot0rEzYMxq7x3IMPmAXFwkfDG17T4=.467be34c-52e2-4cdd-83ac-3b3ad3c16e1e@github.com>
Message-ID: <y7e8gM7OgXHFS7fCJHe_AzLRzdKwHd6KIpPxsvx1ycc=.8601f5ef-7652-485d-987b-75fb8c867155@github.com>

On Tue, 16 Aug 2022 06:26:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "*if an I/O error has occurred*" description in the throws section.
>> 
>> Do you propose to be more specific there and write something like "*if an I/O error has occurred or the end of the input buffer has been reached*"?
>
>> Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "_if an I/O error has occurred_" description in the throws section.
>> 
>> Do you propose to be more specific there and write something like "_if an I/O error has occurred or the end of the input buffer has been reached_"?
> 
> Like many JDK 1.1 era APIs, InflaterInputStream is very under-specified. In this case, the protected fill method is begging us to specify how it behaves when the input is at EOF. An I/O error is surprising here as it also sets the protected len field to indicate EOF. We can't change it after 25 years so we will need to specify existing behavior.

OK, I've opened [JDK-8292427: Improve specification of InflaterInputStream.fill()](https://bugs.openjdk.org/browse/JDK-8292427) to track this.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From vkempik at openjdk.org  Tue Aug 16 09:15:12 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 16 Aug 2022 09:15:12 GMT
Subject: RFR: 8292407: Improve Weak* VarHandle tests resilience under
 spurious failures
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <4IhRaZmWUdCeSPmsNjxXeb8cHTiuvZF54jgDASx8fBw=.929c7b34-6e12-42da-b973-e0201270371c@github.com>

On Tue, 16 Aug 2022 08:23:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Will test on hifive. and let you know the results, meanwhile, can you include these tests into your patch? , they fail with similar symptoms:

hotspot/jtreg/compiler/unsafe/JdkInternalMiscUnsafeAccessTest*.java

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From simonis at openjdk.org  Tue Aug 16 09:18:36 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 09:18:36 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
Message-ID: <MOC6tGcaKSlD2SLQ6ANyuyRlJnyJ175pJPLcnyOlRJA=.bf4ba137-bf42-48eb-a5bb-f6485496da38@github.com>

On Mon, 15 Aug 2022 20:23:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes regarding indentation, naming and spelling

I've updated the link in the description (sorry, copy-paste error) and opened a [JBS issue for `fill()`](https://bugs.openjdk.org/browse/JDK-8292427).

What else is needed to push this to HEAD?

And what do we want to do about JDK 19? Have you read my [last comment](https://bugs.openjdk.org/browse/JDK-8292327?focusedCommentId=14517812&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14517812) in the JBS issue`?

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From alanb at openjdk.org  Tue Aug 16 09:43:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 09:43:17 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
Message-ID: <51el2yH68Ds05qlmpj8hWpBexVqUH9GkkONT-ma8Dxc=.8d302f80-b629-4bbc-b823-4947e4804e87@github.com>

On Mon, 15 Aug 2022 20:23:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes regarding indentation, naming and spelling

test/jdk/java/util/zip/InflaterInputStream/UnexpectedEndOfZlibStream.java line 48:

> 46:         };
> 47:         String deflated = "@ObjectiveCName(\"DYNSApi\")\npackage com.google.apps.dynamite.v1.shared.api;\n\n"+
> 48:             "import com.google.j2objc.annotations.ObjectiveCName;\n\n";

Can you replace the deflated text with something that doesn't look like it came from a google repository?

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From alanb at openjdk.org  Tue Aug 16 09:58:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 09:58:34 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <MOC6tGcaKSlD2SLQ6ANyuyRlJnyJ175pJPLcnyOlRJA=.bf4ba137-bf42-48eb-a5bb-f6485496da38@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
 <MOC6tGcaKSlD2SLQ6ANyuyRlJnyJ175pJPLcnyOlRJA=.bf4ba137-bf42-48eb-a5bb-f6485496da38@github.com>
Message-ID: <a2LJLD5rWskBMr1JX4jNu6M7wZejF8102IkRdegv3sQ=.8a7387a5-03ce-486e-8fc7-2574728b1184@github.com>

On Tue, 16 Aug 2022 09:15:03 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> And what do we want to do about JDK 19? 

It's not a P1 so I don't think it's a change for the RC builds. It is a regression in 19 so we will need to create a RN-KnownIssue release note (I will do that).

I agree with Lance's suggestion to revert JDK-8281962 in JDK 19u. It might be that in the future that you want to re-do the original change for a future 19 update but I think we should give the changes in the main line time to bake.

Separately, we need a high priority issue to create tests for this area. We also need to fix the specification of the fill method as we've been discussing here.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From alanb at openjdk.org  Tue Aug 16 10:00:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 10:00:16 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
In-Reply-To: <_9jRaj6gXaBHpNnmSqibSGRDejSvzj2mu9XcZJybbd8=.6e694073-5fa6-43e1-ab46-a18e6c3c0bcd@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
 <_9jRaj6gXaBHpNnmSqibSGRDejSvzj2mu9XcZJybbd8=.6e694073-5fa6-43e1-ab46-a18e6c3c0bcd@github.com>
Message-ID: <Z2njIrhl1n179PgxvW6mb3m8Xea6avxqASOFwgwmMEg=.cd40b0ea-2a09-4814-988d-41f14b219efd@github.com>

On Tue, 16 Aug 2022 09:06:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.
>
> test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 84:
> 
>> 82:             testCase(42, ttl -> { ttl.set(NULL); ttl.remove(); ttl.get();     }, 42  ),
>> 83:             testCase(42, ttl -> { ttl.get();     ttl.remove(); ttl.set(NULL); }, NULL),
>> 84:         };
> 
> Hm, what about expanding the test cases programmatically. Like this?
> https://github.com/plevart/jdk/commit/ffc681f3cccfdf473d4cc037e5f3e50f8172eec3
> ...it's easier to follow. Some nits included...

> Hm, what about expanding the test cases programmatically. Like this?
> [plevart at ffc681f](https://github.com/plevart/jdk/commit/ffc681f3cccfdf473d4cc037e5f3e50f8172eec3)
> ...it's easier to follow. Some nits included...

I'm not sure that it's any easier to follow but I don't mind merging it in. The other cleanup is good.

-------------

PR: https://git.openjdk.org/jdk/pull/9819

From jwaters at openjdk.org  Tue Aug 16 10:15:39 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 16 Aug 2022 10:15:39 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <w6_7EXLFgimOxoW8VWmAF7c4URKJoX616C7KvYAvsQE=.7f3368ec-e550-4d83-a700-1e76e53e6ea8@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Shift conflict check to end
 - Conflict check can be folded

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a1fc9cd3..0c07454b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=07-08

  Stats: 36 lines in 1 file changed: 15 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Tue Aug 16 10:23:31 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 16 Aug 2022 10:23:31 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/0c07454b..e271f0a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=08-09

  Stats: 29 lines in 1 file changed: 4 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From vkempik at openjdk.org  Tue Aug 16 10:37:29 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 16 Aug 2022 10:37:29 GMT
Subject: RFR: 8292407: Improve Weak* VarHandle tests resilience under
 spurious failures
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <l9pmIx11zitM_jVbq7y-d065qiPHvDukEFu7358xD8Y=.178257b3-104c-4b08-bf6b-1132a07ccfba@github.com>

On Tue, 16 Aug 2022 08:23:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Results on hifive, running all tests in VarHandles dir:

Test results: passed: 22; failed: 2; error: 14

many tests timed out:

VarHandleTestAccessChar.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 127589ms).

VarHandleTestAccessInt.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122091ms).

VarHandleTestAccessLong.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122116ms).

VarHandleTestByteArrayAsFloat.jtr:test result: Error. Program `bin/java' timed out (timeout set to 360000ms, elapsed time including timeout handling was 362103ms).

VarHandleTestByteArrayAsInt.jtr:test result: Error. Program `bin/java' timed out (timeout set to 360000ms, elapsed time including timeout handling was 362061ms).

VarHandleTestMethodHandleAccessBoolean.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122087ms).

VarHandleTestMethodHandleAccessByte.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122059ms).

VarHandleTestMethodHandleAccessChar.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122106ms).

VarHandleTestMethodHandleAccessDouble.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122093ms).

VarHandleTestMethodHandleAccessFloat.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122092ms).

VarHandleTestMethodHandleAccessInt.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122081ms).

VarHandleTestMethodHandleAccessLong.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122123ms).

VarHandleTestMethodHandleAccessShort.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122096ms).

VarHandleTestMethodHandleAccessString.jtr:test result: Error. Program `bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122217ms).`

-------

two failed as before:

`
test VarHandleTestAccessShort.testAccess("VarHandle -> Array", VarHandle -> Array): failure
java.lang.AssertionError: weakCompareAndSetRelease short expected [true] but found [false]
        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:819)
        at VarHandleTestAccessShort.testArray(VarHandleTestAccessShort.java:1073)
        at VarHandleBaseTest$AccessTestCase.testAccess(VarHandleBaseTest.java:421)
        at VarHandleTestAccessShort.testAccess(VarHandleTestAccessShort.java:288)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
        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.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:1589)
`

similar with  VarHandleTestAccessChar: 

java.lang.AssertionError: weakCompareAndSetRelease char expected [true] but found [false]

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From alanb at openjdk.org  Tue Aug 16 11:12:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 11:12:35 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []" [v2]
In-Reply-To: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
Message-ID: <5Y1SbxVqOGvSnKMbqLiJW5YQMXGtRLKX2LNqjhcQmCo=.7b346f5f-5639-4b7c-9140-369bfa0378f2@github.com>

> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecesary check
 - Merge ffc681f3cccfdf473d4cc037e5f3e50f8172eec3 from plevart

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9819/files
  - new: https://git.openjdk.org/jdk/pull/9819/files/0689fd44..126584bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9819&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9819&range=00-01

  Stats: 55 lines in 1 file changed: 17 ins; 24 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9819.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9819/head:pull/9819

PR: https://git.openjdk.org/jdk/pull/9819

From simonis at openjdk.org  Tue Aug 16 11:27:23 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 11:27:23 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <51el2yH68Ds05qlmpj8hWpBexVqUH9GkkONT-ma8Dxc=.8d302f80-b629-4bbc-b823-4947e4804e87@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
 <51el2yH68Ds05qlmpj8hWpBexVqUH9GkkONT-ma8Dxc=.8d302f80-b629-4bbc-b823-4947e4804e87@github.com>
Message-ID: <0i54syPZbcaFMk46TXB1Ovyg-JQSt9Rl3i8mYR19ITU=.6e3f0684-877f-4904-a240-232f8b7a54ba@github.com>

On Tue, 16 Aug 2022 09:41:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor changes regarding indentation, naming and spelling
>
> test/jdk/java/util/zip/InflaterInputStream/UnexpectedEndOfZlibStream.java line 48:
> 
>> 46:         };
>> 47:         String deflated = "@ObjectiveCName(\"DYNSApi\")\npackage com.google.apps.dynamite.v1.shared.api;\n\n"+
>> 48:             "import com.google.j2objc.annotations.ObjectiveCName;\n\n";
> 
> Can you replace the deflated text with something that doesn't look like it came from a google repository?

First of all I just realized that `deflated` is the wrong name, it should actually be `inflated`.

The deflated source (in `bytes`) is the payload which triggers the bug and I can't simply change the string to which it decompresses :)

I'll try to find another, more innocent string such that its compressed version also triggers the bug.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From plevart at openjdk.org  Tue Aug 16 12:41:26 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 16 Aug 2022 12:41:26 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []" [v2]
In-Reply-To: <5Y1SbxVqOGvSnKMbqLiJW5YQMXGtRLKX2LNqjhcQmCo=.7b346f5f-5639-4b7c-9140-369bfa0378f2@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
 <5Y1SbxVqOGvSnKMbqLiJW5YQMXGtRLKX2LNqjhcQmCo=.7b346f5f-5639-4b7c-9140-369bfa0378f2@github.com>
Message-ID: <WmIYT8DeL4700yhDeM4QvsQE7Uw9eLpRiknfPVUkWTc=.8082de93-7fc4-40f1-a15c-5b3770aca4e1@github.com>

On Tue, 16 Aug 2022 11:12:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.
>
> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unnecesary check
>  - Merge ffc681f3cccfdf473d4cc037e5f3e50f8172eec3 from plevart

This looks good.

-------------

Marked as reviewed by plevart (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9819

From ecaspole at openjdk.org  Tue Aug 16 14:35:14 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 16 Aug 2022 14:35:14 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
 [v2]
In-Reply-To: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
Message-ID: <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>

> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Clean up imports and shorten run time preserving result stability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9733/files
  - new: https://git.openjdk.org/jdk/pull/9733/files/b5ee0670..fd244b64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9733&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9733&range=00-01

  Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9733.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9733/head:pull/9733

PR: https://git.openjdk.org/jdk/pull/9733

From ecaspole at openjdk.org  Tue Aug 16 14:41:16 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 16 Aug 2022 14:41:16 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
 [v2]
In-Reply-To: <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
 <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
Message-ID: <Pk7tTlSPtoOm2VKzpRb93swtNRNf1f1Lq14sAdlOwRE=.fd028210-8f0c-40aa-9b25-1fb2959cfc03@github.com>

On Tue, 16 Aug 2022 14:35:14 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up imports and shorten run time preserving result stability

These last changes reduce the run time to about 4h45m with adequate result stability.

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From rriggs at openjdk.org  Tue Aug 16 14:51:30 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Aug 2022 14:51:30 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v6]
In-Reply-To: <eYpXsqNpaDptZS3iMPH7xoyxWWimkkV7SU7mUNdtwuI=.baf726b6-6aab-47a3-b194-cc2fd303985f@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <eYpXsqNpaDptZS3iMPH7xoyxWWimkkV7SU7mUNdtwuI=.baf726b6-6aab-47a3-b194-cc2fd303985f@github.com>
Message-ID: <hz_vRzRCcIouUmjxxu-uiF9Uo3slW3QbTcr-WK6_aac=.4b2146cf-a9cb-4fde-b15e-91ced540af3e@github.com>

On Wed, 10 Aug 2022 01:54:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> JDK-8289106: Add model of class file versions to core reflection
>
> 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 18 additional commits since the last revision:
> 
>  - Implement code review feedback.
>  - Update ClassFileVersionTest.java.
>  - Merge branch 'master' into JDK-8289106
>  - Appease jcheck.
>  - Finish more precise versioned location support; udpate tests.
>  - Partial implementation of version-depdendent locations() with tests.
>  - Merge branch 'master' into JDK-8289106
>  - Merge branch 'master' into JDK-8289106
>  - Add method to map from major class file version.
>  - Merge branch 'master' into JDK-8289106
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/b9293502...2e6dfc8e

Looks good.

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 259:

> 257:     RELEASE_20(64);
> 258: 
> 259:     private int major;

Could be final?

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9299

From shade at openjdk.org  Tue Aug 16 15:14:59 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Aug 2022 15:14:59 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
Message-ID: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>

I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.

The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.

Additional testing:
 - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
 - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
 - [ ]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/9892/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292443
  Stats: 2926 lines in 46 files changed: 2240 ins; 0 del; 686 mod
  Patch: https://git.openjdk.org/jdk/pull/9892.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9892/head:pull/9892

PR: https://git.openjdk.org/jdk/pull/9892

From shade at openjdk.org  Tue Aug 16 15:48:15 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Aug 2022 15:48:15 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v2]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyrights
 - Also do Unsafe tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9889/files
  - new: https://git.openjdk.org/jdk/pull/9889/files/56e8f65a..b4f3890c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=00-01

  Stats: 410 lines in 47 files changed: 344 ins; 0 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From psandoz at openjdk.org  Tue Aug 16 16:00:16 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 Aug 2022 16:00:16 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <U2CDRDPxgj0fQLLYJuFjS-0BqC-D1_MA3s0HpxOVyTk=.93192f21-4400-4260-b2a9-c7ea0a1c458b@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [ ]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9892

From ecaspole at openjdk.org  Tue Aug 16 16:04:24 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 16 Aug 2022 16:04:24 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
 [v2]
In-Reply-To: <KNwp5VuBH0YyqtVlRsdRkOM9rcgb1_ppIjoeeXJ-jOU=.4098b6ed-0ae0-4ac4-bfa5-7f920055bad7@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
 <KNwp5VuBH0YyqtVlRsdRkOM9rcgb1_ppIjoeeXJ-jOU=.4098b6ed-0ae0-4ac4-bfa5-7f920055bad7@github.com>
Message-ID: <INYdYmRD4SRtDevzhsb-0tH36FuXMJA3RtdAggtnQVM=.e4c5f2bc-d3ce-4be1-8a13-3095c4491635@github.com>

On Mon, 15 Aug 2022 14:34:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up imports and shorten run time preserving result stability
>
> test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedSum.java line 33:
> 
>> 31: import org.openjdk.jmh.annotations.Mode;
>> 32: import org.openjdk.jmh.annotations.OutputTimeUnit;
>> 33: import org.openjdk.jmh.annotations.Param;
> 
> Ditto imports vs annotations.

These last changes reduce the run time to about 4h45m with adequate result stability.

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From snazarki at openjdk.org  Tue Aug 16 16:30:20 2022
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 16 Aug 2022 16:30:20 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v2]
In-Reply-To: <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
Message-ID: <6eDRhsisJQz_CU3vPeCSWFy7obXC1gmKcBrBZjb74OM=.a2983c5e-0e82-4ace-b031-6d4b18fbb49f@github.com>

On Tue, 16 Aug 2022 15:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyrights
>  - Also do Unsafe tests

Tested aarch64 on AWS a1.xlarge instance: the issue is gone completely.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From psandoz at openjdk.org  Tue Aug 16 16:39:18 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 Aug 2022 16:39:18 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <Mmwuh_Bp0Y4XNHQCPbw61P1FfGXO9KJq521h5n_4Z_Q=.253bb475-5230-4a81-95ab-edd3c5221bf6@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <Mmwuh_Bp0Y4XNHQCPbw61P1FfGXO9KJq521h5n_4Z_Q=.253bb475-5230-4a81-95ab-edd3c5221bf6@github.com>
Message-ID: <Oo57tTWiGdGOJzeaJfPL94WdVLg2PJ_Hy9hKv-bqPDA=.628dbe90-b94f-4119-86f1-970e252acad4@github.com>

On Fri, 5 Aug 2022 21:58:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Please add JMH microbenchmark and show results.

Also please update the unit tests to run with and without the intrinsics enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From psandoz at openjdk.org  Tue Aug 16 16:47:16 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 Aug 2022 16:47:16 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <Bjs9oBqtc7UBhJ5ryXeH2wLy_H76pFgqLTrT1rkCD24=.9af4035e-9179-49cb-b59b-5864f6b00dd7@github.com>

On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

I would like to propose an alternative separation based on types. We can split into four for refs, ints, longs, and doubles, each extending from the same abstract class with shared code.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From simonis at openjdk.org  Tue Aug 16 17:34:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 17:34:58 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v3]
In-Reply-To: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
Message-ID: <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>

> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
> 
> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
> 
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Changed the payload to a more innocent version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9881/files
  - new: https://git.openjdk.org/jdk/pull/9881/files/3bbfacf1..35d80f6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9881&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9881&range=01-02

  Stats: 23 lines in 1 file changed: 7 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/9881.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9881/head:pull/9881

PR: https://git.openjdk.org/jdk/pull/9881

From simonis at openjdk.org  Tue Aug 16 17:34:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 17:34:58 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <0i54syPZbcaFMk46TXB1Ovyg-JQSt9Rl3i8mYR19ITU=.6e3f0684-877f-4904-a240-232f8b7a54ba@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
 <51el2yH68Ds05qlmpj8hWpBexVqUH9GkkONT-ma8Dxc=.8d302f80-b629-4bbc-b823-4947e4804e87@github.com>
 <0i54syPZbcaFMk46TXB1Ovyg-JQSt9Rl3i8mYR19ITU=.6e3f0684-877f-4904-a240-232f8b7a54ba@github.com>
Message-ID: <YTezAcKbTIbWk_mG-C93fIlT7OYRJXxsVL4wMwo7epQ=.5cefc4ec-c7b5-439e-a6ce-94535bbded0d@github.com>

On Tue, 16 Aug 2022 11:25:03 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> test/jdk/java/util/zip/InflaterInputStream/UnexpectedEndOfZlibStream.java line 48:
>> 
>>> 46:         };
>>> 47:         String deflated = "@ObjectiveCName(\"DYNSApi\")\npackage com.google.apps.dynamite.v1.shared.api;\n\n"+
>>> 48:             "import com.google.j2objc.annotations.ObjectiveCName;\n\n";
>> 
>> Can you replace the uncompressed text with something that doesn't look like it came from a google repository?
>
> First of all I just realized that `deflated` is the wrong name, it should actually be `inflated`.
> 
> The deflated source (in `bytes`) is the payload which triggers the bug and I can't simply change the string to which it decompresses :)
> 
> I'll try to find another, more innocent string such that its compressed version also triggers the bug.

Last commit contains as more neutral payload text.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From jjg at openjdk.org  Tue Aug 16 17:37:29 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Aug 2022 17:37:29 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <mY_ICKm2YiPrsuAYYYJbJCpX3dSMDD3WpUxp5KnR_Mg=.8d1bce53-7139-4986-be60-a9445fe12745@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

`jdk.compiler` and `jdk.javadoc` changes look OK

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9445

From naoto at openjdk.org  Tue Aug 16 17:48:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Aug 2022 17:48:39 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <xzJJkvV1oqcon8KDl5Z8u4KJlP6Udn77VaNko0wHbxA=.83d42205-be39-43b0-be36-17fb59192479@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Those `.properties` bundle changes look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9445

From sgehwolf at openjdk.org  Tue Aug 16 17:53:18 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Aug 2022 17:53:18 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <hTriiUGiOdX19F7kEtSKxqT_F4wMW3WMlFDQd3S1urE=.467382a1-a23f-424e-9dc1-631a17cef62f@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

Don't close bot, please.

-------------

PR: https://git.openjdk.org/jdk/pull/8629

From alanb at openjdk.org  Tue Aug 16 17:55:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 17:55:20 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <YTezAcKbTIbWk_mG-C93fIlT7OYRJXxsVL4wMwo7epQ=.5cefc4ec-c7b5-439e-a6ce-94535bbded0d@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
 <51el2yH68Ds05qlmpj8hWpBexVqUH9GkkONT-ma8Dxc=.8d302f80-b629-4bbc-b823-4947e4804e87@github.com>
 <0i54syPZbcaFMk46TXB1Ovyg-JQSt9Rl3i8mYR19ITU=.6e3f0684-877f-4904-a240-232f8b7a54ba@github.com>
 <YTezAcKbTIbWk_mG-C93fIlT7OYRJXxsVL4wMwo7epQ=.5cefc4ec-c7b5-439e-a6ce-94535bbded0d@github.com>
Message-ID: <5LGeAh2VWkh1HlN66k5N2kyPjvjjJS71gZvs8W0re1Y=.23f0ced5-156b-40cc-9a11-43a90a5d5972@github.com>

On Tue, 16 Aug 2022 17:31:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> First of all I just realized that `deflated` is the wrong name, it should actually be `inflated`.
>> 
>> The deflated source (in `bytes`) is the payload which triggers the bug and I can't simply change the string to which it decompresses :)
>> 
>> I'll try to find another, more innocent string such that its compressed version also triggers the bug.
>
> Last commit contains as more neutral payload text.

Thanks for the update to change the payload.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From darcy at openjdk.org  Tue Aug 16 18:24:23 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Aug 2022 18:24:23 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v6]
In-Reply-To: <hz_vRzRCcIouUmjxxu-uiF9Uo3slW3QbTcr-WK6_aac=.4b2146cf-a9cb-4fde-b15e-91ced540af3e@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <eYpXsqNpaDptZS3iMPH7xoyxWWimkkV7SU7mUNdtwuI=.baf726b6-6aab-47a3-b194-cc2fd303985f@github.com>
 <hz_vRzRCcIouUmjxxu-uiF9Uo3slW3QbTcr-WK6_aac=.4b2146cf-a9cb-4fde-b15e-91ced540af3e@github.com>
Message-ID: <JpWSAa37VqUgChHQt62Z1IRzosZdDJIx8fahOD7_8JY=.d5344fb4-cb09-4c6d-a94d-bacdb78ab955@github.com>

On Tue, 16 Aug 2022 14:40:41 GMT, Roger Riggs <rriggs 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 18 additional commits since the last revision:
>> 
>>  - Implement code review feedback.
>>  - Update ClassFileVersionTest.java.
>>  - Merge branch 'master' into JDK-8289106
>>  - Appease jcheck.
>>  - Finish more precise versioned location support; udpate tests.
>>  - Partial implementation of version-depdendent locations() with tests.
>>  - Merge branch 'master' into JDK-8289106
>>  - Merge branch 'master' into JDK-8289106
>>  - Add method to map from major class file version.
>>  - Merge branch 'master' into JDK-8289106
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/9da21735...2e6dfc8e
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 259:
> 
>> 257:     RELEASE_20(64);
>> 258: 
>> 259:     private int major;
> 
> Could be final?

Sure; that is a better expression of the intent of the field. Will change before pushing; thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From iris at openjdk.org  Tue Aug 16 18:26:17 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Aug 2022 18:26:17 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RHDfWJb7R7zhWFU08KXiXDqIvgJTkdn3fXSazBi58HE=.dfd63f3c-0ae8-45b4-a43d-5d48a17c6337@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9445

From darcy at openjdk.org  Tue Aug 16 18:42:26 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Aug 2022 18:42:26 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v7]
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <ReXYOMMKlxdgWfzJueBz06i1B79DcM6zToxnVXUwOw0=.1847a9db-a174-42a7-828d-87623d2a5056@github.com>

> JDK-8289106: Add model of class file versions to core reflection

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 20 additional commits since the last revision:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8289106
 - Implement code review feedback.
 - Update ClassFileVersionTest.java.
 - Merge branch 'master' into JDK-8289106
 - Appease jcheck.
 - Finish more precise versioned location support; udpate tests.
 - Partial implementation of version-depdendent locations() with tests.
 - Merge branch 'master' into JDK-8289106
 - Merge branch 'master' into JDK-8289106
 - ... and 10 more: https://git.openjdk.org/jdk/compare/6251d510...19f8a2a7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9299/files
  - new: https://git.openjdk.org/jdk/pull/9299/files/2e6dfc8e..19f8a2a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=05-06

  Stats: 7346 lines in 313 files changed: 3412 ins; 2227 del; 1707 mod
  Patch: https://git.openjdk.org/jdk/pull/9299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299

PR: https://git.openjdk.org/jdk/pull/9299

From darcy at openjdk.org  Tue Aug 16 18:46:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Aug 2022 18:46:32 GMT
Subject: Integrated: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <5ZN0VD-VdCYawyXd4Jy4-oA8Lj0fzX_R1EGWlbHIRJU=.4b88fb35-a28d-4d2f-abc7-d7bfc646b218@github.com>

On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8289106: Add model of class file versions to core reflection

This pull request has now been integrated.

Changeset: e44e3f0c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e44e3f0c1976a513c6637545f49f49de84cbac02
Stats:     805 lines in 6 files changed: 760 ins; 1 del; 44 mod

8289106: Add model of class file versions to core reflection

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From alanb at openjdk.org  Tue Aug 16 19:05:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Aug 2022 19:05:19 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v3]
In-Reply-To: <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>
Message-ID: <w8ia0PUo03cE_2mmQj0ws486vaK6HtXbR0RZAOcW33I=.8e0fec9d-d26f-4e23-b31b-ff4ad419cf40@github.com>

On Tue, 16 Aug 2022 17:34:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the payload to a more innocent version

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From rriggs at openjdk.org  Tue Aug 16 19:39:34 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Aug 2022 19:39:34 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <PIPGyHgzw00aa4QSQoAbspSKdGvZY3BdxSpEcD_D_Zk=.7ab3019d-27cf-411f-a6b7-c1ac27b0af98@github.com>

On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

Splitting is as good a technique as any.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9845

From rriggs at openjdk.org  Tue Aug 16 19:43:18 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Aug 2022 19:43:18 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
 [v2]
In-Reply-To: <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
 <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
Message-ID: <IMYaa_4TjMhbVa_z5oC_XzJPqKGX5u4CaZUvxSxFF-s=.72eea2b1-06a9-4f6d-90c3-0ba72bf8dd28@github.com>

On Tue, 16 Aug 2022 14:35:14 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up imports and shorten run time preserving result stability

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From simonis at openjdk.org  Tue Aug 16 19:45:37 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 16 Aug 2022 19:45:37 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v2]
In-Reply-To: <a2LJLD5rWskBMr1JX4jNu6M7wZejF8102IkRdegv3sQ=.8a7387a5-03ce-486e-8fc7-2574728b1184@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <Ss5OfbaxMZRQEOV4UhyiRMljI_vTJZNE-pYxFXaiVow=.0a0b91f6-e38b-45b7-be95-993dc893dfef@github.com>
 <MOC6tGcaKSlD2SLQ6ANyuyRlJnyJ175pJPLcnyOlRJA=.bf4ba137-bf42-48eb-a5bb-f6485496da38@github.com>
 <a2LJLD5rWskBMr1JX4jNu6M7wZejF8102IkRdegv3sQ=.8a7387a5-03ce-486e-8fc7-2574728b1184@github.com>
Message-ID: <B1d6ob76366ODeoLpnr9iq-OyncFpw4Sl13YU6wnFFU=.9e271440-659b-460d-8f6e-296efe3f93cd@github.com>

On Tue, 16 Aug 2022 09:53:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I've updated the link in the description (sorry, copy-paste error) and opened a [JBS issue for `fill()`](https://bugs.openjdk.org/browse/JDK-8292427).
>> 
>> What else is needed to push this to HEAD?
>> 
>> And what do we want to do about JDK 19? Have you read my [last comment](https://bugs.openjdk.org/browse/JDK-8292327?focusedCommentId=14517812&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14517812) in the JBS issue`?
>
>> And what do we want to do about JDK 19? 
> 
> It's not a P1 so I don't think it's a change for the RC builds. It is a regression in 19 so we will need to create a RN-KnownIssue release note (I will do that).
> 
> I agree with Lance's suggestion to revert JDK-8281962 in JDK 19u. It might be that in the future that you want to re-do the original change for a future 19 update but I think we should give the changes in the main line time to bake.
> 
> Separately, we need a high priority issue to create tests for this area. We also need to fix the specification of the fill method as we've been discussing here.

Thanks for the review @AlanBateman.

I'll wait with the integration until tomorrow to also give the colleagues in the US time zone a chance to look at the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From lancea at openjdk.org  Tue Aug 16 20:03:12 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 16 Aug 2022 20:03:12 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v3]
In-Reply-To: <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>
Message-ID: <Zrj56fasaWOwkahsOuDeD1j4iSHDQpmaPM9M3kM62eU=.12d34906-031c-4422-9613-21c308703ae9@github.com>

On Tue, 16 Aug 2022 17:34:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the payload to a more innocent version

This looks OK Volker.

It would be nice if possible to add another test or two prior to pushing as an extra sanity check.  If not, a follow on would be ideal.

I assume you have run Mach1-3 and the JCK tests for extra sanity?

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9881

From dcubed at openjdk.org  Tue Aug 16 22:57:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Aug 2022 22:57:26 GMT
Subject: RFR: 8292509: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows
Message-ID: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>

Trivial fixes to ProblemList two different tests.

-------------

Commit messages:
 - 8292510: ProblemList runtime/cds/appcds/cacheObject/ArchivedEnumTest.java
 - 8292509: ProblemList java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows

Changes: https://git.openjdk.org/jdk/pull/9894/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292509
  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9894.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9894/head:pull/9894

PR: https://git.openjdk.org/jdk/pull/9894

From darcy at openjdk.org  Tue Aug 16 22:57:26 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Aug 2022 22:57:26 GMT
Subject: RFR: 8292509: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows
In-Reply-To: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>
References: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>
Message-ID: <sxDztV1_iQedOIZx--diV5otURS2JZ5mZZHjixr7MSw=.b2296ed9-cbc0-4c07-97fc-9b9d4e1c0cf3@github.com>

On Tue, 16 Aug 2022 22:43:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList two different tests.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9894

From dcubed at openjdk.org  Tue Aug 16 22:57:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Aug 2022 22:57:26 GMT
Subject: RFR: 8292509: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows
In-Reply-To: <sxDztV1_iQedOIZx--diV5otURS2JZ5mZZHjixr7MSw=.b2296ed9-cbc0-4c07-97fc-9b9d4e1c0cf3@github.com>
References: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>
 <sxDztV1_iQedOIZx--diV5otURS2JZ5mZZHjixr7MSw=.b2296ed9-cbc0-4c07-97fc-9b9d4e1c0cf3@github.com>
Message-ID: <nd_fhuYFJ9paHCiU8arMcULJ_mOmyfz9mMHVeyd2oeM=.aedaed6b-f03d-40c6-b2ca-aeb97c730b3f@github.com>

On Tue, 16 Aug 2022 22:47:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial fixes to ProblemList two different tests.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review. I'm now waiting for the bots to catch up...

-------------

PR: https://git.openjdk.org/jdk/pull/9894

From dcubed at openjdk.org  Tue Aug 16 23:06:22 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Aug 2022 23:06:22 GMT
Subject: Integrated: 8292509: ProblemList
 java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows
In-Reply-To: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>
References: <sB3fL8FqoidhViQTOdBMjuxUGCOu2REoMk_Xr3AOBQk=.7a0349f1-5e6b-4757-bf3f-99f8f52959d8@github.com>
Message-ID: <eMNU7zejuNt744IqxANqxuJUa4XdYQQuD0z9bs2H3tM=.dcb3c40f-7d0a-4b05-9f86-2897613d0842@github.com>

On Tue, 16 Aug 2022 22:43:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList two different tests.

This pull request has now been integrated.

Changeset: da477b13
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da477b13661b39e1f48b674f7fd9ea1d26521fc3
Stats:     3 lines in 2 files changed: 3 ins; 0 del; 0 mod

8292509: ProblemList java/lang/invoke/lambda/LogGeneratedClassesTest.java on windows
8292510: ProblemList runtime/cds/appcds/cacheObject/ArchivedEnumTest.java

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/9894

From duke at openjdk.org  Tue Aug 16 23:31:19 2022
From: duke at openjdk.org (Chris Hennick)
Date: Tue, 16 Aug 2022 23:31:19 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v14]
In-Reply-To: <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
Message-ID: <i0goNPi9w15bXMIxfe4r3zNgbTc5HjSF3MhEs1JWLUM=.30650969-7a4f-43a3-87cc-5c7c828dc63b@github.com>

On Sun, 19 Jun 2022 23:38:36 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the 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 greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite Javadoc

Keep open

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From alanb at openjdk.org  Wed Aug 17 07:23:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Aug 2022 07:23:31 GMT
Subject: RFR: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []" [v3]
In-Reply-To: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
Message-ID: <Gdaeym-G5_ASmiSmZTfyMCReH0OqrLpeJKmV0fP-N50=.0310ef0e-ca02-4cd6-b9dd-0c277fd34d93@github.com>

> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge
 - Merge
 - Remove unnecesary check
 - Merge ffc681f3cccfdf473d4cc037e5f3e50f8172eec3 from plevart
 - Convert to TestNG and run all tests on a virtual thread
 - Merge
 - Change test to use custom scheduler, easier to test reliably

-------------

Changes: https://git.openjdk.org/jdk/pull/9819/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9819&range=02
  Stats: 143 lines in 2 files changed: 45 ins; 55 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/9819.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9819/head:pull/9819

PR: https://git.openjdk.org/jdk/pull/9819

From alanb at openjdk.org  Wed Aug 17 07:32:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Aug 2022 07:32:09 GMT
Subject: Integrated: 8292051:
 jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
 failed "AssertionError: Expected terminated values: [666] but got: []"
In-Reply-To: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
References: <7cfRTgk2-9IvSJ7YZV9GtFxLZ4NxfMMYkrYFCZ-kSJg=.8ec2c7fe-2d74-49d3-9407-af3ce1106edc@github.com>
Message-ID: <R9sp2f8mjWa6ujX6hHRXxu_woEUs0CMHmz80Cus5qmM=.8e07be5b-a837-4a34-b5f9-6b4113328b04@github.com>

On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Change the test to use a custom scheduler so there is better control on when the carrier threads terminates. Also convert test to TestNG so that all test cases can be run in the context of a virtual thread.

This pull request has now been integrated.

Changeset: 0bfb1216
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bfb12162f6035559a114176115b91aff6df3b64
Stats:     143 lines in 2 files changed: 45 ins; 55 del; 43 mod

8292051: jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java failed "AssertionError: Expected terminated values: [666] but got: []"

Co-authored-by: Peter Levart <plevart at openjdk.org>
Reviewed-by: plevart

-------------

PR: https://git.openjdk.org/jdk/pull/9819

From shade at openjdk.org  Wed Aug 17 08:08:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 08:08:17 GMT
Subject: RFR: 8292352: 32-bit Windows build failures after JDK-8290059
In-Reply-To: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
References: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
Message-ID: <P1xK2DBxxXZjkQqQ7xNcLGuAntMGLAvR_DHcKKX5zxI=.c03cc0a3-007b-4511-a603-c40b8c68f1f2@github.com>

On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The affected file was added by [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled for tests. Looks like we really need the "WINAPI" macro in the definition, so that we match the stdcall. See the example declaration in the [docs](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85)).
> 
> Attn @JornVernee.
> 
> Additional testing:
>  - [x] Windows x86_32 builds/test now pass
>  - [x]  Windows x86_64 builds/test still pass

All right, thanks! If there are no other suggestions/complaints, I am going to integrate it.

-------------

PR: https://git.openjdk.org/jdk/pull/9875

From shade at openjdk.org  Wed Aug 17 08:14:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 08:14:25 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
Message-ID: <aT4zRRCnP8hkHvxnOj44mCzq0yq57wxFrnC9t3-JcVA=.4fddcd01-d07d-4cc5-9a8d-85aaf0e3f0f9@github.com>

On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev 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:
> 
>  - Also improve newSizedString8859_1
>  - Merge branch 'master' into JDK-8289049-gcc11-x86-32
>  - Init buf in newStringCp1252
>  - Another fix
>  - Fix

Thank you! Any other comments? I'll be integrating it soon otherwise.

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From shade at openjdk.org  Wed Aug 17 08:24:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 08:24:12 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <3PSiqU3SAEWrKKag48RKiPuDd6iViCqh4MbGB3Gaook=.5792e789-54ce-4060-85f9-9df8474d523f@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [ ]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

Still testing aarch64, but I expect it to complete fine. If there are no other comments, I'll integrate this soon.

-------------

PR: https://git.openjdk.org/jdk/pull/9892

From aoqi at openjdk.org  Wed Aug 17 08:36:28 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 17 Aug 2022 08:36:28 GMT
Subject: Integrated: 8292362:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some
 platforms
In-Reply-To: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
References: <JwGEbKXVOe6RRQonmBpm7rmBXrhjgqM1YOxJgZ5Xz5A=.2c4336af-8ed0-4ce2-a474-d15a38234ed7@github.com>
Message-ID: <poXTfgmLZHt-XYF5HHpnDgx66z6d3VYaFsckcQqqonA=.9295fe5c-25e6-4f0f-8c2f-8eef8ab39881@github.com>

On Mon, 15 Aug 2022 12:23:41 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on LoongArch64 (probably other platforms unsupported in src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the same issue):
>  
> 
> Exception in thread "main" java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Linux, loongarch64, 64
> at java.base/jdk.internal.foreign.CABI.current(CABI.java:69)
> at java.base/jdk.internal.foreign.abi.SharedUtils.getSystemLinker(SharedUtils.java:237)
> at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:198)
> at ImplicitAttach.main(ImplicitAttach.java:48)

This pull request has now been integrated.

Changeset: e61f6fc3
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e61f6fc3940720f6ebc3ef360e25b880729cfa5a
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8292362: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed on some platforms

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9877

From stuefe at openjdk.org  Wed Aug 17 08:59:15 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 Aug 2022 08:59:15 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
Message-ID: <mbbfK-cfh2FJwG_gleQx_lepAeyYYph5CLDNpCwBmbs=.cc612f66-7b81-42e7-87e0-c5a2b6bb5712@github.com>

On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev 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:
> 
>  - Also improve newSizedString8859_1
>  - Merge branch 'master' into JDK-8289049-gcc11-x86-32
>  - Init buf in newStringCp1252
>  - Another fix
>  - Fix

I'm confused. How does adding EnsureCapacity in newString646_US fix the compiler warning mentioned in JBS?

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From simonis at openjdk.org  Wed Aug 17 09:34:18 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 Aug 2022 09:34:18 GMT
Subject: RFR: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962 [v3]
In-Reply-To: <Zrj56fasaWOwkahsOuDeD1j4iSHDQpmaPM9M3kM62eU=.12d34906-031c-4422-9613-21c308703ae9@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
 <FNeefkOwK0jAW-Ag9yWqTlXrWDGPJMdmh1oLj4GsgpQ=.3a7b6315-9bfa-4d70-8fac-892e54f54d7c@github.com>
 <Zrj56fasaWOwkahsOuDeD1j4iSHDQpmaPM9M3kM62eU=.12d34906-031c-4422-9613-21c308703ae9@github.com>
Message-ID: <8S39w_ps5JSHdul3x1SgpYdaOp0BhZMs-nIcM0JISW0=.538bd49b-a914-4ea2-bd4f-e750ac685b1b@github.com>

On Tue, 16 Aug 2022 20:01:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the payload to a more innocent version
>
> This looks OK Volker.
> 
> It would be nice if possible to add another test or two prior to pushing as an extra sanity check.  If not, a follow on would be ideal.
> 
> I assume you have run Mach1-3 and the JCK tests for extra sanity?

Hi @LanceAndersen,

Thanks for the review. I can't run Mach 1-3 because it's Oracle internal but I've run the corresponding JCK tests.

I think more and better tests should be done as a follow-up task as suggested by Alan.

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From simonis at openjdk.org  Wed Aug 17 09:37:29 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 Aug 2022 09:37:29 GMT
Subject: Integrated: 8292327: java.io.EOFException in InflaterInputStream after
 JDK-8281962
In-Reply-To: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
References: <8S6pHRsqoGZxuphyzb_J4DAJf1XCC2_f2zL8muyHkSE=.f9ef412d-6353-483b-8f39-1f1ec5f422f4@github.com>
Message-ID: <p7bkw5ejQnQoZCeHtKFok2KrB_ZMDaGoRCeJdcwoAfM=.20488777-15be-407a-9d2a-493d4e525f09@github.com>

On Mon, 15 Aug 2022 17:43:27 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
> 
> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
> 
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."

This pull request has now been integrated.

Changeset: 802ef380
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/802ef38060080254e55621e4c64fa31a6c0b7b18
Stats:     93 lines in 3 files changed: 92 ins; 0 del; 1 mod

8292327: java.io.EOFException in InflaterInputStream after JDK-8281962

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/9881

From xgong at openjdk.org  Wed Aug 17 09:52:18 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 17 Aug 2022 09:52:18 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>
Message-ID: <PnuaR1w_is-cf38fQvXTnnPwgyv3GKrfh8Sy-N0NC1M=.118c4a4d-3082-43f5-83b4-0dcb8e3eb0d1@github.com>

On Mon, 15 Aug 2022 16:17:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Looks good.

Thanks for looking at this patch @PaulSandoz ! 

> Much better to flip the operation and the receiver + first arg to the blend.

I'm not quite understand what the flip operation here mean. The current code is simple enough to me. Could you please show more details? Thanks a lot!

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From shade at openjdk.org  Wed Aug 17 11:09:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 11:09:13 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <mbbfK-cfh2FJwG_gleQx_lepAeyYYph5CLDNpCwBmbs=.cc612f66-7b81-42e7-87e0-c5a2b6bb5712@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
 <mbbfK-cfh2FJwG_gleQx_lepAeyYYph5CLDNpCwBmbs=.cc612f66-7b81-42e7-87e0-c5a2b6bb5712@github.com>
Message-ID: <DfyLnxEqlJjZFEsNhMqcDPy9UcO8rGGYanjQB-ihHxk=.c0b3986a-76f8-4cb7-995d-08a2cf397efb@github.com>

On Wed, 17 Aug 2022 08:55:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I'm confused. How does adding EnsureCapacity in newString646_US fix the compiler warning mentioned in JBS?

I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles this code fine. So, we have two options: a) disable the warnings for this code block; b) harmonize all code blocks to use the same style, which is also incidentally avoids the false warning. This PR does (b).

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From stuefe at openjdk.org  Wed Aug 17 11:30:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 Aug 2022 11:30:37 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
Message-ID: <OfrKb-PBg3aeDYLv6jkMbWqbloj5OUWL66CYc9YI1OQ=.602e468f-c676-4000-9784-f884afe738a9@github.com>

On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev 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:
> 
>  - Also improve newSizedString8859_1
>  - Merge branch 'master' into JDK-8289049-gcc11-x86-32
>  - Init buf in newStringCp1252
>  - Another fix
>  - Fix

Looks good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9702

From stuefe at openjdk.org  Wed Aug 17 11:30:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 Aug 2022 11:30:37 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <DfyLnxEqlJjZFEsNhMqcDPy9UcO8rGGYanjQB-ihHxk=.c0b3986a-76f8-4cb7-995d-08a2cf397efb@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
 <mbbfK-cfh2FJwG_gleQx_lepAeyYYph5CLDNpCwBmbs=.cc612f66-7b81-42e7-87e0-c5a2b6bb5712@github.com>
 <DfyLnxEqlJjZFEsNhMqcDPy9UcO8rGGYanjQB-ihHxk=.c0b3986a-76f8-4cb7-995d-08a2cf397efb@github.com>
Message-ID: <99HIxSwqkjJh8KgORcfSrfAOWRoTaUiI0w9-TFSVIHo=.13b84264-b8d4-4a6b-8cfa-afbfd14f7b8c@github.com>

On Wed, 17 Aug 2022 11:05:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I'm confused. How does adding EnsureCapacity in newString646_US fix the compiler warning mentioned in JBS?
> 
> I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles this code fine. So, we have two options: a) disable the warnings for this code block; b) harmonize all code blocks to use the same style, which is also incidentally avoids the false warning. This PR does (b).

Okay, fair enough.

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From vkempik at openjdk.org  Wed Aug 17 12:49:39 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Wed, 17 Aug 2022 12:49:39 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v2]
In-Reply-To: <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
Message-ID: <zzyAo6jQwn-DIpMwVWMk8-9s2feZNJB1G7RWsxDG7Kc=.acec5980-f019-4f34-840c-ca086c1ce72e@github.com>

On Tue, 16 Aug 2022 15:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyrights
>  - Also do Unsafe tests

new patch test results: thead rvb-ice - all good.
hifive unmatched: some tests still fail intermittently ( with timeout factor 10, to prevent them timing out):
VarHandleTestAccessShort.java
VarHandleTestMethodHandleAccess*.java

Will probably have to ignore these in test runs.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From shade at openjdk.org  Wed Aug 17 12:53:19 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 12:53:19 GMT
Subject: RFR: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning [v3]
In-Reply-To: <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
 <ctweBK1nWBsHv48XU9yklhEg-zd7KZecaOJ7zZ4LRW4=.9967dabd-57d4-4a46-9469-6cd6819f2d00@github.com>
Message-ID: <HFaA0lGB5yLw_CWyyWEE4nDcF6lu-tRD6qkYwtENd18=.3e1839a4-1a83-4503-b51c-9173acd16473@github.com>

On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
>> 
>> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 build with GCC 11
>>  - [x]  Linux x86_32 `tier1` test with GCC 9
>>  - [x]  Linux x86_64 `tier1` test with GCC 9
>
> Aleksey Shipilev 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:
> 
>  - Also improve newSizedString8859_1
>  - Merge branch 'master' into JDK-8289049-gcc11-x86-32
>  - Init buf in newStringCp1252
>  - Another fix
>  - Fix

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From shade at openjdk.org  Wed Aug 17 12:54:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 12:54:47 GMT
Subject: Integrated: 8289049: x86_32 build fails with GCC 11 due to
 newString646_US warning
In-Reply-To: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
References: <Lgh5EwxME9PbmXTC8ukIO3YWv7grU-y1IZ0NZt8_apQ=.62670b47-e2fd-4709-9234-c8ff4fb8fcee@github.com>
Message-ID: <ssxSYLcgbVUdMyhqbAw5crpDiKiwIQSCBReZ8U8AbPA=.cb62cf53-a271-4b8c-93fb-7f0d5d0f0875@github.com>

On Mon, 1 Aug 2022 11:46:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug report for reproducer and error message. The warning looks quite superficial, and I initially suspected that it complains about `int len = (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the similar code in `newStringCp1252`  apparently does not produce the warning: https://github.com/openjdk/jdk/blob/f5d1b5bda27c798347ae278cbf69725ed4be895c/src/java.base/share/native/libjava/jni_util.c#L533-L566
> 
> I propose we chalk it up to false/odd compiler warning and sync up unproblematic `newStringCp1252` and `newString646_US` implementation to dodge it.
> 
> Additional testing:
>  - [x] Linux x86_32 build with GCC 11
>  - [x]  Linux x86_32 `tier1` test with GCC 9
>  - [x]  Linux x86_64 `tier1` test with GCC 9

This pull request has now been integrated.

Changeset: 0c67fba1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c67fba11f444cc3739f66c8a2d57564b5dcca72
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8289049: x86_32 build fails with GCC 11 due to newString646_US warning

Reviewed-by: alanb, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/9702

From shade at openjdk.org  Wed Aug 17 13:27:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 13:27:35 GMT
Subject: Integrated: 8292352: 32-bit Windows build failures after JDK-8290059
In-Reply-To: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
References: <DZaduZxSdGLJjy5fCsJ2lFCdrr7jPOax172ilw4vRGY=.15ed7324-afea-4c26-ad0f-c8366eec0b2c@github.com>
Message-ID: <yEjeuZ1tDpkozb0D8I-mqTdq51FlphvBzmzfq1ghzOI=.81433a20-52db-476c-83a5-de66bf66b804@github.com>

On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The affected file was added by [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled for tests. Looks like we really need the "WINAPI" macro in the definition, so that we match the stdcall. See the example declaration in the [docs](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85)).
> 
> Attn @JornVernee.
> 
> Additional testing:
>  - [x] Windows x86_32 builds, `java/foreign` tests now pass
>  - [x] Windows x86_64 builds, `java/foreign` tests still pass

This pull request has now been integrated.

Changeset: e81210f5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e81210f5fe03ea3dc9c9fb0dba2be79e1dcc03bc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8292352: 32-bit Windows build failures after JDK-8290059

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/9875

From ecaspole at openjdk.org  Wed Aug 17 15:00:29 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 17 Aug 2022 15:00:29 GMT
Subject: RFR: 8291828: Reduce runtime of java.util.stream microbenchmarks
 [v2]
In-Reply-To: <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
 <rnyZxlVQG91ORWe9rnQXAN-sfvD9DmZN70mU6sApaqs=.df65f4a5-7dde-4b98-b9df-335f3c487092@github.com>
Message-ID: <UEHny6A3auULFqxtohmsAnftPyLL6B-jfxebkpUFk9s=.ea5e499c-4d0e-4071-ac90-a3ccb3fed73a@github.com>

On Tue, 16 Aug 2022 14:35:14 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up imports and shorten run time preserving result stability

Thanks Roger!

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From ecaspole at openjdk.org  Wed Aug 17 15:04:26 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 17 Aug 2022 15:04:26 GMT
Subject: Integrated: 8291828: Reduce runtime of java.util.stream
 microbenchmarks
In-Reply-To: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
References: <cP3wm4TmPd2sY-7tT728E3OKG0FDR7fcmw-n2jPIgNw=.3bd33fc6-e72f-4afe-8199-296ef0ea0d88@github.com>
Message-ID: <kfz46Ai_VVWc3onOUnfIeer_LMvC4h75hKlh96LhfAg=.dcde2f8a-388f-488a-9ab4-7d8464af1b77@github.com>

On Wed, 3 Aug 2022 16:28:31 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the default run time from about 1 day 22 hours to about 6 hours with good stability we can use in weekly testing.

This pull request has now been integrated.

Changeset: 0fc92637
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fc92637d297d9a1281df33089975bd6d5fdf809
Stats:     367 lines in 62 files changed: 360 ins; 0 del; 7 mod

8291828: Reduce runtime of java.util.stream microbenchmarks

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9733

From psandoz at openjdk.org  Wed Aug 17 15:20:19 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Aug 2022 15:20:19 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <PnuaR1w_is-cf38fQvXTnnPwgyv3GKrfh8Sy-N0NC1M=.118c4a4d-3082-43f5-83b4-0dcb8e3eb0d1@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>
 <PnuaR1w_is-cf38fQvXTnnPwgyv3GKrfh8Sy-N0NC1M=.118c4a4d-3082-43f5-83b4-0dcb8e3eb0d1@github.com>
Message-ID: <9yLjZcGBbRtdXeL3NiyO8IoTW7SJ315Z1Zra1JB5uyE=.9bd541c7-a5fd-4857-8e12-8062a87cfbe5@github.com>

On Wed, 17 Aug 2022 09:48:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Much better to flip the operation and the receiver + first arg to the blend.
> 
> I'm not quite understand what the flip operation here mean. The current code is simple enough to me. Could you please show more details? Thanks a lot!

I mean to say your approach is much better: changing `ne` to `eq` and changing the arguments to the blend.

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From rriggs at openjdk.org  Wed Aug 17 15:40:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Aug 2022 15:40:04 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer pipes
 than expected
Message-ID: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>

Revised test to check and close all of the streams used in the pipeline.

The test now checks the content length and closes each stdout and stderr stream.

The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

-------------

Commit messages:
 - 8291760: PipelineLeaksFD.java still fails: More or fewer pipes than expected

Changes: https://git.openjdk.org/jdk/pull/9905/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291760
  Stats: 13 lines in 2 files changed: 5 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9905/head:pull/9905

PR: https://git.openjdk.org/jdk/pull/9905

From mchhipa at openjdk.org  Wed Aug 17 15:41:10 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 17 Aug 2022 15:41:10 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
Message-ID: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>

Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

-------------

Commit messages:
 - JDK-8289510 : Improve test coverage for XPath Axes: namespace

Changes: https://git.openjdk.org/jdk/pull/9906/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289510
  Stats: 163 lines in 1 file changed: 163 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9906/head:pull/9906

PR: https://git.openjdk.org/jdk/pull/9906

From mchhipa at openjdk.org  Wed Aug 17 15:41:10 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 17 Aug 2022 15:41:10 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <S0KLhY43HxngiZU_UdMlS4Co51Q56MS9CIprjek7iM4=.c2bb8d0f-7e52-4c40-82b4-1a7f702ea930@github.com>

On Wed, 17 Aug 2022 15:32:49 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

Hi @JoeWang-Java , Could you please review this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9906

From svkamath at openjdk.org  Wed Aug 17 17:35:39 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 17 Aug 2022 17:35:39 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v2]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <zljLsRW9qiZ2nLj7iRctPHIhuFpOyAAVaoOgkfc3BmQ=.1cb32376-e63c-435c-a1a0-a91c4bbf62df@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Added a jmh microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/d04fb405..bcbc2f56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=00-01

  Stats: 96 lines in 1 file changed: 96 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Wed Aug 17 17:36:53 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 17 Aug 2022 17:36:53 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <u5znQBh35QNIK-XnWPa3TNCqNVgat0sAuBhOc2m8en4=.a782d5bf-ed2c-400f-ad5e-d0c941f52d0a@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

JMH results
Before patch
Benchmark                                               (TESTSIZE)   Mode  Cnt    Score   Error   Units
Fp16ConversionBenchmark.float16ToFloat        2048  thrpt    3  359.680 ? 0.292  ops/ms
Fp16ConversionBenchmark.floatToFloat16        2048  thrpt    3  236.153 ? 8.164  ops/ms

After patch
Benchmark                                               (TESTSIZE)   Mode  Cnt     Score   Error   Units
Fp16ConversionBenchmark.float16ToFloat        2048  thrpt    3  1046.233 ? 0.019  ops/ms
Fp16ConversionBenchmark.floatToFloat16        2048  thrpt    3  1752.046 ? 0.058  ops/ms

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From bpb at openjdk.org  Wed Aug 17 17:59:35 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Aug 2022 17:59:35 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v2]
In-Reply-To: <FpWbLjYzZQt7fqNs-XUmqAnxZpHkN75XsOSQfQjm0Hw=.cfe5262d-12a3-41f5-9d5c-3df39ac1c1e5@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
 <FpWbLjYzZQt7fqNs-XUmqAnxZpHkN75XsOSQfQjm0Hw=.cfe5262d-12a3-41f5-9d5c-3df39ac1c1e5@github.com>
Message-ID: <FBu0R7pNLZ06dizYJqMpJ6mqhUbOg0OdA6TLUcUbbVU=.87905468-581e-48ab-97d6-bee3847d606c@github.com>

On Fri, 12 Aug 2022 15:13:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8291911: Account for quotas on Windows.
>
> test/jdk/java/io/File/GetXSpace.java line 244:
> 
>> 242:                 // reported by df might be less that the actual total space in
>> 243:                 // the store, but the free space should be the same.
>> 244:                 if (!(Platform.isWindows() && ts > s.total && fs == s.free())) {
> 
> Unsure of the conditional here, in particular whether `fs == s.free()` is needed. Also, when failure is suppressed here, an informational print might be useful.

Changed the conditional in 991dc9a6bf86e3ec54fd1c244c655a86506a697d.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From bpb at openjdk.org  Wed Aug 17 17:59:34 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Aug 2022 17:59:34 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v2]
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <PAUFPRZ0OYt3MXRK2q77fOyiePIzHI8TrOYAjvWJLCQ=.62917036-86fa-4a30-b6a5-b45b8da6c61c@github.com>

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8291911: Account for quotas on Windows.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9856/files
  - new: https://git.openjdk.org/jdk/pull/9856/files/af2d6f50..991dc9a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=00-01

  Stats: 34 lines in 1 file changed: 13 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9856.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9856/head:pull/9856

PR: https://git.openjdk.org/jdk/pull/9856

From psandoz at openjdk.org  Wed Aug 17 18:00:20 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Aug 2022 18:00:20 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v2]
In-Reply-To: <zljLsRW9qiZ2nLj7iRctPHIhuFpOyAAVaoOgkfc3BmQ=.1cb32376-e63c-435c-a1a0-a91c4bbf62df@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <zljLsRW9qiZ2nLj7iRctPHIhuFpOyAAVaoOgkfc3BmQ=.1cb32376-e63c-435c-a1a0-a91c4bbf62df@github.com>
Message-ID: <tmsRK5vBk_MCq5cLcaidj3sMn8nBlqT8OeoL8htLvhQ=.128f190c-d3e8-43df-92a1-e079575ed903@github.com>

On Wed, 17 Aug 2022 17:35:39 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a jmh microbenchmark

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 38:

> 36: 
> 37:   @Param({"2048"})
> 38:   public int TESTSIZE;

Suggestion:

  public int size;

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 40:

> 38:   public int TESTSIZE;
> 39: 
> 40:   public short[] HFargV1;

Let's use `F16` instead of `HF`.
e.g. f16in, f16out, fin, fout.

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 59:

> 57:       Random r = new Random(1024);
> 58: 
> 59:       HFargV1 = new short[TESTSIZE];

If the test size is less than the number of special values then we will get an exception. I cannot quite decide if special values are that important here. Might be better to test separately?

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 85:

> 83:   @Benchmark
> 84:   public void floatToFloat16() {
> 85:       for (int i = 0; i < TESTSIZE; i++) {

Use the array length instead, it's more idiomatic e.g.:
Suggestion:

      for (int i = 0; i < FargV1.length; i++) {

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 88:

> 86:           ResHF[i] = Float.floatToFloat16(FargV1[i]);
> 87:       }
> 88:   }

Return the result array, so it's consumed by a black hole.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From shade at openjdk.org  Wed Aug 17 18:08:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 18:08:33 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <sq9lP_eRQ_3TGFKq-erqePbfACJtfNvTVKBa3n1k74Q=.317c31ea-a98f-4c5a-bd8f-c783a443b22b@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

Finally, AArch64 testing is complete. Results look good. I am integrating to unblock other test stabilization work.

-------------

PR: https://git.openjdk.org/jdk/pull/9892

From shade at openjdk.org  Wed Aug 17 18:17:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Aug 2022 18:17:28 GMT
Subject: Integrated: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <XmHI54mdovqSxNtSkIWLToCspV66WxAc3RtcZdaEgYs=.4b6121e6-0c7f-4262-b2bf-99e53f7c3f31@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

This pull request has now been integrated.

Changeset: e8bc8795
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8bc87956abc92851de8694c56a78f6ecc546cbd
Stats:     2926 lines in 46 files changed: 2240 ins; 0 del; 686 mod

8292443: Weak CAS VarHandle/Unsafe tests should test always-failing cases

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/9892

From bpb at openjdk.org  Wed Aug 17 18:29:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Aug 2022 18:29:17 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v2]
In-Reply-To: <PAUFPRZ0OYt3MXRK2q77fOyiePIzHI8TrOYAjvWJLCQ=.62917036-86fa-4a30-b6a5-b45b8da6c61c@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
 <PAUFPRZ0OYt3MXRK2q77fOyiePIzHI8TrOYAjvWJLCQ=.62917036-86fa-4a30-b6a5-b45b8da6c61c@github.com>
Message-ID: <DN-OL8CnJR-0fJ-zrWMjxY64NIPzc-zK3tA9edvZBXs=.b8629cb4-2204-4b70-b54f-4b1dce19a044@github.com>

On Wed, 17 Aug 2022 17:59:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291911: Account for quotas on Windows.

The version of the test in commit 991dc9a6bf86e3ec54fd1c244c655a86506a697d passed 5 repeats on Linux and macOS and 51 repeats on Windows, including on a node on which it previously failed.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From some-java-user-99206970363698485155 at vodafonemail.de  Wed Aug 17 20:35:53 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Wed, 17 Aug 2022 22:35:53 +0200
Subject: Reduce / avoid ConditionalSpecialCasing.lookUpTable temporary memory
 allocation
Message-ID: <cadb7f25ad394002a532cd3a06e190f4@vodafonemail.de>

Hello,
originally I reported this on the bug tracker, but was asked to first post this topic to this mailing list. I was told that afterwards the bug report will be created.

The internal method `java.lang.ConditionalSpecialCasing#lookUpTable` is used for special case conversion rules, and is called when either the specified locale has special casing rules (e.g. Turkish) or the string to convert contains characters with special casing rules, for example U+0130 (Latin Capital Letter I with Dot Above). The problem with this method is that it creates temporary objects. Given that the method is in the worst case called for every character (possibly even twice per character), this can cause a lot of temporary memory allocation for large strings.

Below is the original bug report description (slightly modified), with a proposal how it can (at least in parts) be implemented without allocating any temporary objects; feedback is appreciated. I am not a JDK member and therefore cannot submit a pull request for this.

Kind regards

--------------------------

There are two issues with the method `lookUpTable` of the internal class java.lang.ConditionalSpecialCasing which is used for special case conversion:
- It uses the int codepoint as key for a Map<Integer, ...> to look up the case conversion; therefore this wraps the int as an Integer
- The special case conversion entries are stored in a HashSet<Entry>
  - First of all usage of a Set seems redundant because Entry does not even override `equals` and it look like always distinct Entry instances are added to the Set
  - Usage of a Set means a new Iterator object is created whenever case conversion entries are found for a code point

It looks like both of this can be fixed, for example in the following way:
1. Remove ConditionalSpecialCasing.Entry.ch (and the corresponding getter)
2. Remove the static field ConditionalSpecialCasing.entry
3. For every existing entry add a static final field `entry<codepoint>` storing a Entry[]  (<codepoint> being a placeholder for the codepoint hex string)
4. In ConditionalSpecialCasing.lookUpTable use a `switch` to access the corresponding `entry...`

Here is a short example snippet showing that:
```
private static final Entry[] entry0069 = {
    new Entry(new char[]{0x0069}, new char[]{0x0130}, "tr", 0), // # LATIN SMALL LETTER I
    new Entry(new char[]{0x0069}, new char[]{0x0130}, "az", 0) // # LATIN SMALL LETTER I
};
...

private static char[] lookUpTable(String src, int index, Locale locale, boolean bLowerCasing) {
    Entry[] entries = switch (src.codePointAt(index)) {
        case 0x0069 -> entry0069;
        ...
        default -> null;
    };
    char[] ret = null;

    if (entries != null) {
        String currentLang = locale.getLanguage();
        for (Entry entry : entries) {
            String conditionLang = entry.getLanguage();
            ...
        }
    }

    return ret;
}
```


Note: `java.lang.ConditionalSpecialCasing.isFinalCased` is also quite problematic because it creates a new StringCharacterIterator and a RuleBasedBreakIterator for each call.
Unfortunately I don't know of an easy way how this can be avoided; it would be great if you could investigate solving this nonetheless, in the worst case with ThreadLocal or simiar.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Profile the object allocations of the `toLowerCase` calls of the following code snippets, for example with VisualVM:

1. Snippet:
```
String s = "\u0130".repeat(1000);
s.toLowerCase(Locale.ROOT);
```

2. Snippet:
```
String s = "\u03A3".repeat(1000);
s.toLowerCase(Locale.ROOT);
```


ACTUAL -
1. Snippet:
2000 Integer objects created
2000 HashMap$KeyIterator objects created

2. Snippet:
1000 Integer objects created
1000 HashMap$KeyIterator objects created
1000 StringCharacterIterator objects created
1000 RuleBasedBreakIterator objects created


From some-java-user-99206970363698485155 at vodafonemail.de  Wed Aug 17 21:07:17 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Wed, 17 Aug 2022 23:07:17 +0200
Subject: Why does CompletableFuture use ThreadPerTaskExecutor?
Message-ID: <ef719df011054fe78873dccd989a2286@vodafonemail.de>

Hello,
when ForkJoinPool.getCommonPoolParallelism() is < 2, CompletableFuture uses a ThreadPerTaskExecutor. As the name implies,
that executor creates a new thread per task.
My question is, why is it implemented this way?

This approach can cause drastic performance decreases for applications making heavy use of CompletableFuture. For example when
I ran a program on a machine with 2 CPU cores, the program took ~40 minutes. After manually specifying an executor for CompletableFuture
which simply runs the tasks in the current thread, the program took ~5 minutes. I assume this was caused by the extensive context
switching for hundreds of threads running concurrently.

A similar extreme case occurred for Minecraft Java Edition in the past where this caused the game to run out of memory because it
created too many threads (https://bugs.mojang.com/browse/MC-137353): OutOfMemoryError: unable to create new native thread

This is tracked already by https://bugs.openjdk.org/browse/JDK-8213115, but unfortunately it looks like that report received little attention
so far. I am a bit afraid that a lot of applications are negatively affected by this (also on GitHub hosted workflow runners which run with
2 CPU cores), but in most cases application developers dismiss this as general performance issues (possibly assuming the hardware
is to blame) without drawing the connection to CompletableFuture.

After digging a bit in the Git history, it appears this behavior was introduced by b1a10b8ed7bedb27ae25341602319a11a1225ee7 to
fix test failures for CompletableFuture/Basic.java (JDK-8020435; private report so I don't know the details). However, wouldn't it be more
reasonable to simply use a thread pool with 2 worker threads? That would match the behavior of a machine with 3 CPU cores and is
known to work without issues (otherwise you would have special casing for this scenario as well in the CompletableFuture implementation).

Sorry if bumping JDK bug reports here is not appreciated. After all I solved this issue by simply not using commonPool(), but I am
afraid others are negatively affected by this as well without being aware of this.

Kind regards


From darcy at openjdk.org  Wed Aug 17 22:42:07 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Aug 2022 22:42:07 GMT
Subject: RFR: JDK-8292498: java/lang/invoke/lambda/LogGeneratedClassesTest.java
 failed with "AssertionError: only show error once expected [1] but found [0]"
Message-ID: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>

The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.

Clean tier1 and tier 2 Mach 5 run with these changes.

-------------

Commit messages:
 - JDK-8292498: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with "AssertionError: only show error once expected [1] but found [0]"

Changes: https://git.openjdk.org/jdk/pull/9911/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292498
  Stats: 140 lines in 2 files changed: 66 ins; 1 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/9911.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9911/head:pull/9911

PR: https://git.openjdk.org/jdk/pull/9911

From psandoz at openjdk.org  Wed Aug 17 22:57:13 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Aug 2022 22:57:13 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]"
In-Reply-To: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
Message-ID: <7LiHWI_I9JFfL0L_ysjAibITjW2BJkv4eJaaS2kLsTM=.f315d321-8b30-4c9a-b19a-af610eec5d35@github.com>

On Wed, 17 Aug 2022 22:33:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
> 
> Clean tier1 and tier 2 Mach 5 run with these changes.

Its a shame. Code changes look good. I recommend adding an internal comment within the top of the class declaration indicating why anon inner classes are used, esp. since this there is more action at a distance than the usual case where lambdas are used too early in the JDK initialization process.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9911

From rriggs at openjdk.org  Wed Aug 17 23:04:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Aug 2022 23:04:12 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]"
In-Reply-To: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
Message-ID: <3GDViPXidyZDLrqcnsZlvuMfonGJbhiNny2whq0L7HY=.84588dc8-5488-4524-bc49-ca17a7273d46@github.com>

On Wed, 17 Aug 2022 22:33:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
> 
> Clean tier1 and tier 2 Mach 5 run with these changes.

This is very unfortunate, the reason to use Lambdas was to avoid creating all the subclasses that would be generated by subclassing the location() method.  At least in this form, the subclasses are not initialized until they are used.

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From darcy at openjdk.org  Wed Aug 17 23:11:23 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Aug 2022 23:11:23 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
Message-ID: <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>

> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
> 
> Clean tier1 and tier 2 Mach 5 run with these changes.

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/9911/files
  - new: https://git.openjdk.org/jdk/pull/9911/files/66e90435..722a3508

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9911&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9911&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9911.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9911/head:pull/9911

PR: https://git.openjdk.org/jdk/pull/9911

From darcy at openjdk.org  Wed Aug 17 23:11:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Aug 2022 23:11:24 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <7LiHWI_I9JFfL0L_ysjAibITjW2BJkv4eJaaS2kLsTM=.f315d321-8b30-4c9a-b19a-af610eec5d35@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <7LiHWI_I9JFfL0L_ysjAibITjW2BJkv4eJaaS2kLsTM=.f315d321-8b30-4c9a-b19a-af610eec5d35@github.com>
Message-ID: <fGh2UhWgL9srkEvvwM5coTp2elqgunbTwj1Jv9jCuxA=.e6800ca7-7886-4076-82d5-d6730c67fb7f@github.com>

On Wed, 17 Aug 2022 22:53:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Its a shame. Code changes look good. I recommend adding an internal comment within the top of the class declaration indicating why anon inner classes are used, esp. since this there is more action at a distance than the usual case where lambdas are used too early in the JDK initialization process.

Agree that adding an explanatory comment is a good practice; I thought the same myself shortly after creating the PR :-)

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From mchung at openjdk.org  Thu Aug 18 00:48:23 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 18 Aug 2022 00:48:23 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
Message-ID: <34P-Q7qGuuGuXnapInPslclixk7vxbt9oAC7vn-2nv8=.c6449a0d-dae2-4bef-a377-64a4063f78cb@github.com>

On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
>> 
>> Clean tier1 and tier 2 Mach 5 run with these changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Indeed this is unfortunate.   The change looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9911

From xgong at openjdk.org  Thu Aug 18 01:21:16 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 Aug 2022 01:21:16 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <9yLjZcGBbRtdXeL3NiyO8IoTW7SJ315Z1Zra1JB5uyE=.9bd541c7-a5fd-4857-8e12-8062a87cfbe5@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>
 <PnuaR1w_is-cf38fQvXTnnPwgyv3GKrfh8Sy-N0NC1M=.118c4a4d-3082-43f5-83b4-0dcb8e3eb0d1@github.com>
 <9yLjZcGBbRtdXeL3NiyO8IoTW7SJ315Z1Zra1JB5uyE=.9bd541c7-a5fd-4857-8e12-8062a87cfbe5@github.com>
Message-ID: <e3YhOJzJ5N3ZY01UI4HPRYW0oiTndj-ME8cInQygqmM=.b38ea1b8-62a9-441e-9e13-13c06c937468@github.com>

On Wed, 17 Aug 2022 15:16:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > > Much better to flip the operation and the receiver + first arg to the blend.
> > 
> > 
> > I'm not quite understand what the flip operation here mean. The current code is simple enough to me. Could you please show more details? Thanks a lot!
> 
> I mean to say your approach is much better: changing `ne` to `eq` and changing the arguments to the blend.

Oh, ok, thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From jpai at openjdk.org  Thu Aug 18 01:44:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Aug 2022 01:44:16 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
Message-ID: <N414QK3xlLKmD65NEqPg685eQ--9ZdaUvP-ax_WTFnE=.4858e36d-11de-4381-bb40-e598c3fa0533@github.com>

On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
>> 
>> Clean tier1 and tier 2 Mach 5 run with these changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From jpai at openjdk.org  Thu Aug 18 01:56:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Aug 2022 01:56:16 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <Y8YQUAF6gCQHeo3HX11jxTTawjtNh_3VR3qELYnPVDI=.d0c70440-85b2-4cce-8f55-0526160a0392@github.com>

On Wed, 17 Aug 2022 15:31:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 40:

> 38: /*
> 39:  * @test
> 40:  * @bug 8289643 9291760

Hello Roger, there's a typo here in the new bug id. Should have been `8291760`.
Other than that, the rest of the change looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/9905

From jpai at openjdk.org  Thu Aug 18 02:05:25 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Aug 2022 02:05:25 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <sEgENwXmn0B5-tJIvV3BSe55AkBd78SfekXZOIty_a4=.8e6fd876-58e8-46cb-ae79-1f17dc4f23cd@github.com>

On Wed, 17 Aug 2022 15:31:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9905

From dholmes at openjdk.org  Thu Aug 18 02:48:15 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Aug 2022 02:48:15 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
Message-ID: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>

On Tue, 16 Aug 2022 10:23:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
>> 
>> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

src/java.base/unix/native/libjli/java_md_common.c line 213:

> 211:          */
> 212:         char error[1024];
> 213:         if(strerror_r(errno, error, sizeof error) == 0) {

Style nit: need space after 'if'

This applies to other files too.

src/java.base/windows/native/libjli/java_md.c line 621:

> 619:     char  *errtext = NULL;
> 620: 
> 621:     char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report";

So why not report both of them as part of the message?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From yadongwang at openjdk.org  Thu Aug 18 03:32:16 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Thu, 18 Aug 2022 03:32:16 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v2]
In-Reply-To: <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <cJy6WjFFDjVUyIuTek8BC0QJeWy0J6_gpt9Q3eOns08=.febf6021-8cb6-43ce-b3d1-64fc52c639a0@github.com>
Message-ID: <LNqgZztZivN9Mt7GAuP8WaQkAd85tDT2p-dKT_jtbXo=.c25b2839-2e0d-44c5-bbef-ad634e129643@github.com>

On Tue, 16 Aug 2022 15:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyrights
>  - Also do Unsafe tests

lgtm.

-------------

Marked as reviewed by yadongwang (Author).

PR: https://git.openjdk.org/jdk/pull/9889

From darcy at openjdk.org  Thu Aug 18 05:13:38 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 05:13:38 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs
Message-ID: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>

Spec refinement, including acting on some feedback received for JDK-8266670:

https://github.com/openjdk/jdk/pull/7445#discussion_r906846794

-------------

Commit messages:
 - JDK-8292576: Improve wording of AccessFlag-related specs

Changes: https://git.openjdk.org/jdk/pull/9912/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9912&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292576
  Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9912.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9912/head:pull/9912

PR: https://git.openjdk.org/jdk/pull/9912

From shade at openjdk.org  Thu Aug 18 06:11:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Aug 2022 06:11:39 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v3]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <aAYntY5CP5qoO-1UrspVHlMEAohK2TfV5GwAaRBkh7o=.c65cf1ed-72d8-45af-9be5-93f8c0e6f9ba@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Update copyrights
 - Also do Unsafe tests
 - Fix

-------------

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=02
  Stats: 661 lines in 45 files changed: 640 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From alanb at openjdk.org  Thu Aug 18 07:00:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Aug 2022 07:00:22 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs
In-Reply-To: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
Message-ID: <8O9TJSZnfIw9jCpjgbjqvquTpy4ssDUq3EwHTt7i8AE=.332b3748-b893-42ad-a4ab-d7ab2439ed00@github.com>

On Thu, 18 Aug 2022 05:05:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Spec refinement, including acting on some feedback received for JDK-8266670:
> 
> https://github.com/openjdk/jdk/pull/7445#discussion_r906846794

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 217:

> 215:         /**
> 216:          * {@return an unmodifiable set of the module {@linkplain AccessFlag
> 217:          * requires flags}, possibly empty}

The link fix looks okay but the wording in the new accessFlags() method is different to the wording in the other methods. The other methods use "possibly-empty unmodifiable" in the return description. Either is fine but I think we should try to keep the wording consistent where possible.

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From jwaters at openjdk.org  Thu Aug 18 08:14:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 08:14:18 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
Message-ID: <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>

On Thu, 18 Aug 2022 02:39:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup
>
> src/java.base/windows/native/libjli/java_md.c line 621:
> 
>> 619:     char  *errtext = NULL;
>> 620: 
>> 621:     char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report";
> 
> So why not report both of them as part of the message?

I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise.

@tstuefe thoughts?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Aug 18 08:23:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 08:23:22 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <XYtwpVTE-9Q0V-cPt_ylvXWx0X6ksFmaGRSUV_vMkX0=.0f02c45c-386a-46ef-9513-a043d7b9e717@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Resolve issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/e271f0a8..a9ff11fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=09-10

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Aug 18 08:25:47 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 08:25:47 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
Message-ID: <_3aw2eO_JUJVFZiJImuWcN0cfBcAAfhzrHmt0AAsc_c=.a929046e-bcb8-4c43-8a77-ec1617692ee2@github.com>

On Thu, 18 Aug 2022 02:36:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup
>
> src/java.base/unix/native/libjli/java_md_common.c line 213:
> 
>> 211:          */
>> 212:         char error[1024];
>> 213:         if(strerror_r(errno, error, sizeof error) == 0) {
> 
> Style nit: need space after 'if'
> 
> This applies to other files too.

Fixed, thanks for the heads up

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From stuefe at openjdk.org  Thu Aug 18 08:56:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Aug 2022 08:56:17 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11]
In-Reply-To: <XYtwpVTE-9Q0V-cPt_ylvXWx0X6ksFmaGRSUV_vMkX0=.0f02c45c-386a-46ef-9513-a043d7b9e717@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <XYtwpVTE-9Q0V-cPt_ylvXWx0X6ksFmaGRSUV_vMkX0=.0f02c45c-386a-46ef-9513-a043d7b9e717@github.com>
Message-ID: <BhjCUjMeeXFRBcUs9jkeu1o1FnsiMAukOIOOidQd_fU=.fc83a521-aa91-49e6-98c2-af01a9efe6b2@github.com>

On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
>> 
>> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolve issues

src/java.base/unix/native/libjli/java_md_common.c line 213:

> 211:          */
> 212:         char error[1024];
> 213:         if (strerror_r(errno, error, sizeof error) == 0) {

Please use brackets with sizeof

src/java.base/windows/native/libjli/java_md.c line 611:

> 609:  * Because Windows API errors and regular errno errors can exist at the same time,
> 610:  * compromise and error out when both are present. Windows code should ideally clear
> 611:  * the last error before a call that sets either of these!

That comment is strange. Of course Windows resets both errno or GetLastError if an API using them is called. But these mechanisms have nothing to do with each other and resetting errno if a WIN32 call is done would be wrong, and vice versa.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From stuefe at openjdk.org  Thu Aug 18 08:56:19 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Aug 2022 08:56:19 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
Message-ID: <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>

On Thu, 18 Aug 2022 08:10:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.base/windows/native/libjli/java_md.c line 621:
>> 
>>> 619:     char  *errtext = NULL;
>>> 620: 
>>> 621:     char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report";
>> 
>> So why not report both of them as part of the message?
>
> I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise.
> 
> @tstuefe thoughts?

Let's back up a bit.

I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows.

But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again?

If we are right and this code is not needed, I'd just scrap this function on Windows altogether.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Aug 18 09:50:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 09:50:16 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
Message-ID: <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>

On Thu, 18 Aug 2022 08:52:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise.
>> 
>> @tstuefe thoughts?
>
> Let's back up a bit.
> 
> I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows.
> 
> But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again?
> 
> If we are right and this code is not needed, I'd just scrap this function on Windows altogether.

8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Aug 18 09:52:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 09:52:37 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <xhfXoB0yVpaNUQ5rWRNv5ZBaLTFuokr6Cf6P76MwDNg=.a8ce96d0-089f-4486-853e-c5dac56dd52a@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Address review concerns

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a9ff11fa..ff398500

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=10-11

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From stuefe at openjdk.org  Thu Aug 18 09:58:10 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Aug 2022 09:58:10 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
 <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
Message-ID: <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>

On Thu, 18 Aug 2022 09:46:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Let's back up a bit.
>> 
>> I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows.
>> 
>> But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again?
>> 
>> If we are right and this code is not needed, I'd just scrap this function on Windows altogether.
>
> 8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it

Okay, this is for future use. We don't usually add complexity as a preparation for the future. We usually include usage and functionality in one RFE. That way reviewers can see how the feature is supposed to be used, and whether its worth to keep it.

You may hear other opinions, but what I would do:

- make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites.
- If that turns out to be many call sites, we can think about adding a windows specific JLI_ReportErrorMessageSysWin32.  
- If that's just 2-5 sites or so, leave it and just scrap JLI_ReportErrorMessageSys for windows.

Just my 5 cent.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Aug 18 11:25:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 11:25:19 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
 <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
 <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>
Message-ID: <HDqtjDNvH9cs_dKBUk9kzzQhVzf6a2e1c8Zy0b4HNB0=.0a44b091-1199-4d9a-87c5-76a2b9a950b2@github.com>

On Thu, 18 Aug 2022 09:55:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it
>
> Okay, this is for future use. We don't usually add complexity as a preparation for the future. We usually include usage and functionality in one RFE. That way reviewers can see how the feature is supposed to be used, and whether its worth to keep it.
> 
> You may hear other opinions, but what I would do:
> 
> - make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites.
> - If that turns out to be many call sites, we can think about adding a windows specific JLI_ReportErrorMessageSysWin32.  
> - If that's just 2-5 sites or so, leave it and just scrap JLI_ReportErrorMessageSys for windows.
> 
> Just my 5 cent.

The (rather incomplete) fix for this was indeed initially part of the original RFE, and only split into another bug afterwards when it was realized there was too much to fit into one PR for an easy review, but I thought it'd be less of a clutter to focus on this one first since the issue already exists in the tracker

> make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites.

I don't quite get what you mean?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From stuefe at openjdk.org  Thu Aug 18 13:26:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Aug 2022 13:26:07 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <HDqtjDNvH9cs_dKBUk9kzzQhVzf6a2e1c8Zy0b4HNB0=.0a44b091-1199-4d9a-87c5-76a2b9a950b2@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
 <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
 <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>
 <HDqtjDNvH9cs_dKBUk9kzzQhVzf6a2e1c8Zy0b4HNB0=.0a44b091-1199-4d9a-87c5-76a2b9a950b2@github.com>
Message-ID: <IuwwcnNhvJZZGUWj_hK9fz-x-wsLsDxP87kK2x-afIM=.64698d51-8ce0-49c0-b88e-423e9880510b@github.com>

On Thu, 18 Aug 2022 11:23:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I don't quite get what you mean?

The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is that it prints the error code for you, and that is a very slim win. It turns into a loss quickly if it does that one thing wrong, e.g. by printing unrelated error codes that confuse the analyst. And if that causes us and you to burn cycles with this discussion that could be spent much better elsewhere.

Therefore, what I meant to suggest is to fix whatever you originally wanted to fix with your original JBS issue https://bugs.openjdk.org/browse/JDK-8291917 by calling JLI_ReportErrorMessage directly.

e.g. 

p = VirtualAlloc(...) or whatever win32 API you want to cover
if (p == NULL) {
  JLI_ReportErrorMessage("Failed to allocate xxx (%u)", GetLastError());
}

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From rriggs at openjdk.org  Thu Aug 18 13:42:06 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Aug 2022 13:42:06 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
Message-ID: <WqNRhWToLHK-7EBKunSG03xZrurWGavOHMG8E7xF8a4=.1893ffdf-7996-4784-93f7-680e1a6b3a95@github.com>

On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
>> 
>> Clean tier1 and tier 2 Mach 5 run with these changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From rriggs at openjdk.org  Thu Aug 18 13:56:41 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Aug 2022 13:56:41 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected [v2]
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <rOrIXZmiaZJQcJ7x1EMHh57asK4cIysD0-uN6k9jQVg=.3f1e4580-3a01-4988-894b-724a7c33485c@github.com>

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into 8291760-leaks-close
 - 8291760: PipelineLeaksFD.java still fails: More or fewer pipes than expected
   Check the contents and close each stdout and stderr stream.

-------------

Changes: https://git.openjdk.org/jdk/pull/9905/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9905&range=01
  Stats: 14 lines in 2 files changed: 5 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9905/head:pull/9905

PR: https://git.openjdk.org/jdk/pull/9905

From dfuchs at openjdk.org  Thu Aug 18 14:58:58 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Aug 2022 14:58:58 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
Message-ID: <X1GBRF1I7VgSlaRCeH8RV6qCOFLmG3rc8VLolRHNn5Y=.ccb2ee38-ec31-4740-bbbf-602cf35b5274@github.com>

On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
>> 
>> Clean tier1 and tier 2 Mach 5 run with these changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Stupid question: it seems none of these lambdas/anonymous classes capture any parameters, all are stateless, and several seems to be identical.  Would it make the code cleaner to use static inner classes?

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From rriggs at openjdk.org  Thu Aug 18 15:27:16 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Aug 2022 15:27:16 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <X1GBRF1I7VgSlaRCeH8RV6qCOFLmG3rc8VLolRHNn5Y=.ccb2ee38-ec31-4740-bbbf-602cf35b5274@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
 <X1GBRF1I7VgSlaRCeH8RV6qCOFLmG3rc8VLolRHNn5Y=.ccb2ee38-ec31-4740-bbbf-602cf35b5274@github.com>
Message-ID: <_O6wurc5WXrQ_zqYzFGUagdzZHhNbGcqzhQEtdncWyc=.c8cbada1-2ca5-4f7b-b7b6-363a358db9b3@github.com>

On Thu, 18 Aug 2022 14:55:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Stupid question: it seems none of these lambdas/anonymous classes capture any parameters, all are stateless, and several seems to be identical. Would it make the code cleaner to use static inner classes?

Keeping the source for the function/body close to or nested in the declaration of each enum is very desirable.

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From jwaters at openjdk.org  Thu Aug 18 15:48:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Aug 2022 15:48:17 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <IuwwcnNhvJZZGUWj_hK9fz-x-wsLsDxP87kK2x-afIM=.64698d51-8ce0-49c0-b88e-423e9880510b@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
 <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
 <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>
 <HDqtjDNvH9cs_dKBUk9kzzQhVzf6a2e1c8Zy0b4HNB0=.0a44b091-1199-4d9a-87c5-76a2b9a950b2@github.com>
 <IuwwcnNhvJZZGUWj_hK9fz-x-wsLsDxP87kK2x-afIM=.64698d51-8ce0-49c0-b88e-423e9880510b@github.com>
Message-ID: <Su6vKXkIaDexcGy1PJxoG-6QqSIpqmdTgRlXw7rfJSE=.d30c2586-2009-4f94-86c9-27c954df54ca@github.com>

On Thu, 18 Aug 2022 13:22:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The (rather incomplete) fix for this was indeed initially part of the original RFE, and only split into another bug afterwards when it was realized there was too much to fit into one PR for an easy review, but I thought it'd be less of a clutter to focus on this one first since the issue already exists in the tracker
>> 
>>> make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites.
>> 
>> I don't quite get what you mean?
>
>> I don't quite get what you mean?
> 
> The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is that it prints the error code for you, and that is a very slim win. It turns into a loss quickly if it does that one thing wrong, e.g. by printing unrelated error codes that confuse the analyst. And if that causes us and you to burn cycles with this discussion that could be spent much better elsewhere.
> 
> Therefore, what I meant to suggest is to fix whatever you originally wanted to fix with your original JBS issue https://bugs.openjdk.org/browse/JDK-8291917 by calling JLI_ReportErrorMessage directly.
> 
> e.g. 
> 
> p = VirtualAlloc(...) or whatever win32 API you want to cover
> if (p == NULL) {
>   JLI_ReportErrorMessage("Failed to allocate xxx (%u)", GetLastError());
> }

Initially I did intend to do that, but a raw GetLastError wouldn't exactly be very helpful when a failure does occur, and unfortunately formatting the proper message from it takes quite a bit of ceremony (Thanks for nothing Win32 API!) that would hopefully be confined to only one function - And it seems so far that this one is quite a suitable candidate. To be sure, that RFE doesn't strictly require this one, and can be changed to use other utilities instead, but as mentioned above the same fault is in Windows error reporting routines all over the JDK, and unlike ReportErrorMessageSys which isn't used that often, those are very commonly used across the codebase, by doing that all we'd be doing is sidestepping the problem and leaving it to be fixed later. I did hope that a warning or outright refusal to concat the errors when either GetLastError and errno != 0 was a good solution, though

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From joehw at openjdk.org  Thu Aug 18 16:09:12 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 18 Aug 2022 16:09:12 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <bDITVnuDSWA8XeiVnwXXIgtAIy140tbOzN1He3fZbQY=.4b645db8-d839-4455-978d-e8a2ab1e99d6@github.com>

On Wed, 17 Aug 2022 15:32:49 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

Thanks Mahendra! 

In general, it would be good to add javadoc/notes to each test and data provider.

The test cases themselves look okay, although they are a bit repetitive in that they are all in the form of a forward axis starting from the root. In practical use cases, it's most useful to perform node test with various namespace-related functions in order to locate a node or nodeset. Namespace changes the way how a node or nodeset is located, e.g. /a/b/c finds c, but as soon as namespace(s) are added, that same xpath expression no longer finds it. I remember sub-task JDK-8289948 (https://github.com/openjdk/jdk/pull/9633) had some of that. It would be good to discuss with Bill @bwhuang-us  or have Bill review this PR, as we talked about more comprehensive test coverage for namespaces in this sub-task.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpNamespaceTest.java line 127:

> 125:                 {"/Customers/Customer/namespace::*", 3},
> 126:                 {"/Customers/Customer/Address/namespace::*", 2},
> 127:                 {"/Customers/Customer/Address/namespace::*", 2},

Duplicate test cases.

-------------

PR: https://git.openjdk.org/jdk/pull/9906

From darcy at openjdk.org  Thu Aug 18 16:12:26 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 16:12:26 GMT
Subject: RFR: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]" [v2]
In-Reply-To: <_O6wurc5WXrQ_zqYzFGUagdzZHhNbGcqzhQEtdncWyc=.c8cbada1-2ca5-4f7b-b7b6-363a358db9b3@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
 <yT_03wHQDUlTtZo3e8XUSvbUInuvR8wFELQ7zG2nL9o=.ab59f5c2-9577-4b84-b568-7c5346068e33@github.com>
 <X1GBRF1I7VgSlaRCeH8RV6qCOFLmG3rc8VLolRHNn5Y=.ccb2ee38-ec31-4740-bbbf-602cf35b5274@github.com>
 <_O6wurc5WXrQ_zqYzFGUagdzZHhNbGcqzhQEtdncWyc=.c8cbada1-2ca5-4f7b-b7b6-363a358db9b3@github.com>
Message-ID: <t_LA1M71Oc1_zQM4jQDfZlXlouAuL7s5NRtT9HJOME0=.f2ec8b1c-1562-48ac-b988-447b086510ed@github.com>

On Thu, 18 Aug 2022 15:23:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Stupid question: it seems none of these lambdas/anonymous classes capture any parameters, all are stateless, and several seems to be identical. Would it make the code cleaner to use static inner classes?
> 
> Keeping the source for the function/body close to or nested in the declaration of each enum is very desirable.

Yes, the enum's method was coded in approximately this way to help with maintenance and readability. If this proves to be troublesome over time, there are harder-to-read/understand refactorings that could be used instead.

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From darcy at openjdk.org  Thu Aug 18 16:12:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 16:12:27 GMT
Subject: Integrated: JDK-8292498:
 java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with
 "AssertionError: only show error once expected [1] but found [0]"
In-Reply-To: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
References: <gyRQ55ftGrKyR-LUoz6_6ijh7nWnhlHiAejLWjLxtfQ=.4b131037-a61a-4747-8cc0-94d8c911dbfb@github.com>
Message-ID: <2CsT4yzwAgWZrB6uUBlJdiZh0JZpHKvk6F4ytrkUIKA=.07e3ded3-5b1f-4c26-9841-ad497f979ea5@github.com>

On Wed, 17 Aug 2022 22:33:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in some cases due to occurring early in the platform's initialization. Instead of lambdas, using anonymous classes gets around the issue.
> 
> Clean tier1 and tier 2 Mach 5 run with these changes.

This pull request has now been integrated.

Changeset: f567fa0f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f567fa0fd53c519cdda1da8a7aaa0df895abc6e9
Stats:     145 lines in 2 files changed: 71 ins; 1 del; 73 mod

8292498: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed with "AssertionError: only show error once expected [1] but found [0]"

Reviewed-by: psandoz, mchung, jpai, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9911

From darcy at openjdk.org  Thu Aug 18 18:20:16 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 18:20:16 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs
In-Reply-To: <8O9TJSZnfIw9jCpjgbjqvquTpy4ssDUq3EwHTt7i8AE=.332b3748-b893-42ad-a4ab-d7ab2439ed00@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
 <8O9TJSZnfIw9jCpjgbjqvquTpy4ssDUq3EwHTt7i8AE=.332b3748-b893-42ad-a4ab-d7ab2439ed00@github.com>
Message-ID: <vhljoFp065GUIXBMhyH_blgwyPJUysAK2fXU_xq36y4=.f4a58679-4d25-4359-b585-3525709a5d0d@github.com>

On Thu, 18 Aug 2022 06:56:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Spec refinement, including acting on some feedback received for JDK-8266670:
>> 
>> https://github.com/openjdk/jdk/pull/7445#discussion_r906846794
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 217:
> 
>> 215:         /**
>> 216:          * {@return an unmodifiable set of the module {@linkplain AccessFlag
>> 217:          * requires flags}, possibly empty}
> 
> The link fix looks okay but the wording in the new accessFlags() method is different to the wording in the other methods. The other methods use "possibly-empty unmodifiable" in the return description. Either is fine but I think we should try to keep the wording consistent where possible.

I've looked over the wording of the various accessFlags methods. The wording for ModuleDescriptor.Requires looks consistent to me:

Returns an unmodifiable set of the module flags, possibly empty.

Returns an unmodifiable set of the module export flags for this module descriptor, possibly empty.

Returns an unmodifiable set of the module opens flags, possibly empty.

Returns an unmodifiable set of the module requires flags, possibly empty.

----

Returns an unmodifiable set of the access flags for this class, possibly empty.

Returns an unmodifiable set of the access flags for the executable represented by this object, possibly empty.

Returns an unmodifiable set of the access flags for this member, possibly empty.

Returns an unmodifiable set of the access flags for the parameter represented by this object, possibly empty.

Am I overlooking something in the twisty passages, all alike?

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From alanb at openjdk.org  Thu Aug 18 19:02:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Aug 2022 19:02:35 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs
In-Reply-To: <vhljoFp065GUIXBMhyH_blgwyPJUysAK2fXU_xq36y4=.f4a58679-4d25-4359-b585-3525709a5d0d@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
 <8O9TJSZnfIw9jCpjgbjqvquTpy4ssDUq3EwHTt7i8AE=.332b3748-b893-42ad-a4ab-d7ab2439ed00@github.com>
 <vhljoFp065GUIXBMhyH_blgwyPJUysAK2fXU_xq36y4=.f4a58679-4d25-4359-b585-3525709a5d0d@github.com>
Message-ID: <GIzSZDhWPK2szEqShmimghwkykL6jsPq1dKgMlaDuLk=.415f6e8a-6dd4-4a7d-ac91-39529f92becb@github.com>

On Thu, 18 Aug 2022 18:16:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 217:
>> 
>>> 215:         /**
>>> 216:          * {@return an unmodifiable set of the module {@linkplain AccessFlag
>>> 217:          * requires flags}, possibly empty}
>> 
>> The link fix looks okay but the wording in the new accessFlags() method is different to the wording in the other methods. The other methods use "possibly-empty unmodifiable" in the return description. Either is fine but I think we should try to keep the wording consistent where possible.
>
> I've looked over the wording of the various accessFlags methods. The wording for ModuleDescriptor.Requires looks consistent to me:
> 
> Returns an unmodifiable set of the module flags, possibly empty.
> 
> Returns an unmodifiable set of the module export flags for this module descriptor, possibly empty.
> 
> Returns an unmodifiable set of the module opens flags, possibly empty.
> 
> Returns an unmodifiable set of the module requires flags, possibly empty.
> 
> ----
> 
> Returns an unmodifiable set of the access flags for this class, possibly empty.
> 
> Returns an unmodifiable set of the access flags for the executable represented by this object, possibly empty.
> 
> Returns an unmodifiable set of the access flags for this member, possibly empty.
> 
> Returns an unmodifiable set of the access flags for the parameter represented by this object, possibly empty.
> 
> Am I overlooking something in the twisty passages, all alike?

If you compare the javadoc for the modifiers vs. accessFlags in each of ModuleDescriptor, Requires, Exports, and Opens then you'll see what I mean. I was hoping they could be inconsistent.

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From rriggs at openjdk.org  Thu Aug 18 19:29:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Aug 2022 19:29:05 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected [v4]
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <er1lVcOiZA8jy08A0y-5-J7uhiV13HSBemw5FpbT-U0=.b3fcec16-9e11-4a45-82c2-e5372f264ee3@github.com>

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8291760-leaks-close
 - Revised test to read, check, and close streams from all processes in the pipeline.
   If any unexpected output is found it is printed.
 - Merge branch 'master' into 8291760-leaks-close
 - 8291760: PipelineLeaksFD.java still fails: More or fewer pipes than expected
   Check the contents and close each stdout and stderr stream.

-------------

Changes: https://git.openjdk.org/jdk/pull/9905/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9905&range=03
  Stats: 28 lines in 2 files changed: 8 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/9905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9905/head:pull/9905

PR: https://git.openjdk.org/jdk/pull/9905

From jjg at openjdk.org  Thu Aug 18 21:58:50 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Aug 2022 21:58:50 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <m5ZXX1-S8ASHLOSqlv_dPHspsLNhNeNt8VbMmAfaeqQ=.f10b2608-7801-4a16-94d6-c0da06aa15d4@github.com>

On Thu, 30 Jun 2022 15:14:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

Mostly excellent.

There are some minor comments inline.

There are more "English phrases" (recognized as "strings with words separated by spaces") than I expected, at least some of which will end up in generated docs. But that being said, I guess this is a JDK-only feature, and we don't translate the source going into our API docs.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 91:

> 89:         /** JEP number */
> 90:         int number() default 0;
> 91:         /** JEP title */

suggest noting the format (i.e. plain text, not HTML, not a resource key)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 164:

> 162:     protected void addIndexLink(HtmlId id, String headingKey, Content content) {
> 163:         var li = HtmlTree.LI(links.createLink(id,
> 164:                 contents.getContent(headingKey))).setId(HtmlId.of("contents-" + id.name()));

Suggest adding a comment that `"contents-" + id` appears in the JavaScript code as well. You presumably can't change one without the other (and can't use a common function across the language barrier.)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 125:

> 123: doclet.Preview_API=Preview API
> 124: doclet.Preview_API_Checkbox_Label=Show preview API for:
> 125: doclet.Preview_JEP_URL=https://openjdk.java.net/jeps/{0}

Use `openjdk.org`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 243:

> 241: }
> 242: ul.contents-list li {
> 243:     font-size: 13px;

Do these values have to be normalized into `.em` units, to align with new themes?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 1346:

> 1344:      * @return the map of PreviewFeature.JEP annotation element values, or an empty map
> 1345:      */
> 1346:     public Map<? extends ExecutableElement, ? extends AnnotationValue> getJepInfo(String feature) {

This method should borderline be in `Workarounds.java` because you are accessing javac internal features, even if only reflectively.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From darcy at openjdk.org  Thu Aug 18 22:44:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 22:44:53 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs [v2]
In-Reply-To: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
Message-ID: <UR4pN2dRAv8KBhvAPHPRhFGKfQvRiHrz20wQO-o8EjE=.013cea22-5515-4816-8399-946a738f99a8@github.com>

> Spec refinement, including acting on some feedback received for JDK-8266670:
> 
> https://github.com/openjdk/jdk/pull/7445#discussion_r906846794

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:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8292576
 - JDK-8292576: Improve wording of AccessFlag-related specs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9912/files
  - new: https://git.openjdk.org/jdk/pull/9912/files/ad8470fe..74940784

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9912&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9912&range=00-01

  Stats: 844 lines in 29 files changed: 305 ins; 227 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/9912.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9912/head:pull/9912

PR: https://git.openjdk.org/jdk/pull/9912

From darcy at openjdk.org  Thu Aug 18 22:44:54 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Aug 2022 22:44:54 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs [v2]
In-Reply-To: <GIzSZDhWPK2szEqShmimghwkykL6jsPq1dKgMlaDuLk=.415f6e8a-6dd4-4a7d-ac91-39529f92becb@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
 <8O9TJSZnfIw9jCpjgbjqvquTpy4ssDUq3EwHTt7i8AE=.332b3748-b893-42ad-a4ab-d7ab2439ed00@github.com>
 <vhljoFp065GUIXBMhyH_blgwyPJUysAK2fXU_xq36y4=.f4a58679-4d25-4359-b585-3525709a5d0d@github.com>
 <GIzSZDhWPK2szEqShmimghwkykL6jsPq1dKgMlaDuLk=.415f6e8a-6dd4-4a7d-ac91-39529f92becb@github.com>
Message-ID: <-niLyH0lL5oqSQmrMOnQ1lzJpihKtryQe-7cI2bbaTs=.ed0acecb-21a1-4420-a04b-87e0235ef4c7@github.com>

On Thu, 18 Aug 2022 18:59:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you compare the javadoc for the modifiers vs. accessFlags in each of ModuleDescriptor, Requires, Exports, and Opens then you'll see what I mean. I was hoping they could be consistent.

Ah, okay. Pushed docs updated as suggested for consistency within ModuleDescriptor.java.

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From duke at openjdk.org  Fri Aug 19 06:56:38 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 06:56:38 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https [v2]
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <SNHwtcq72zY7FsKGHrue2rTaexjNxMUZ4EhdP4GPP2k=.b2171fb9-b781-4f9c-afca-f8f1832ba844@github.com>

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Joe 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 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9445/files
  - new: https://git.openjdk.org/jdk/pull/9445/files/324f877c..07b7be0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=00-01

  Stats: 142897 lines in 2088 files changed: 75388 ins; 52973 del; 14536 mod
  Patch: https://git.openjdk.org/jdk/pull/9445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9445/head:pull/9445

PR: https://git.openjdk.org/jdk/pull/9445

From alanb at openjdk.org  Fri Aug 19 07:25:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 07:25:30 GMT
Subject: RFR: JDK-8292576: Improve wording of AccessFlag-related specs [v2]
In-Reply-To: <UR4pN2dRAv8KBhvAPHPRhFGKfQvRiHrz20wQO-o8EjE=.013cea22-5515-4816-8399-946a738f99a8@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
 <UR4pN2dRAv8KBhvAPHPRhFGKfQvRiHrz20wQO-o8EjE=.013cea22-5515-4816-8399-946a738f99a8@github.com>
Message-ID: <6f4YO91Mv2b2CTvYHLIKcRpvP8ynzoBjQglPji37G8c=.33876347-688a-46b0-aa51-6112717370fb@github.com>

On Thu, 18 Aug 2022 22:44:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Spec refinement, including acting on some feedback received for JDK-8266670:
>> 
>> https://github.com/openjdk/jdk/pull/7445#discussion_r906846794
>
> 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:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8292576
>  - JDK-8292576: Improve wording of AccessFlag-related specs

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From duke at openjdk.org  Fri Aug 19 08:58:59 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 08:58:59 GMT
Subject: Integrated: 8289562: Change bugs.java.com and bugreport.java.com URL's
 to https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <3PKzwl7RxEVyWEBTVdySoL1eKjal-7IRGDANL2ABqG8=.7dc34842-62c6-40a5-8ce3-1bf0e9f58852@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

This pull request has now been integrated.

Changeset: 1f484dae
Author:    Joe <joe.cherian at oracle.com>
Committer: Fairoz Matte <fmatte at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f484dae4efaa60cf18a3d4df947c05f1497bd5b
Stats:     18 lines in 17 files changed: 0 ins; 0 del; 18 mod

8289562: Change bugs.java.com and bugreport.java.com URL's to https

Co-authored-by: Joe Cherian <joe.cherian at oracle.com>
Reviewed-by: prr, jjg, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/9445

From shade at openjdk.org  Fri Aug 19 13:03:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 19 Aug 2022 13:03:47 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <ZDU4X2CxHWZS6niRYSx8ka4ZBq-c7G59Cx6TZsngGLg=.c4513e16-78c2-4da6-a693-1b3a05c345da@github.com>

On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

Looks like `sizes` initialization now gets duplicated too. I think you can do a super-class with these utility methods, the extend the subclasses with actual tests off it.

I agree with @PaulSandoz that we better split it by type. It would also give us meaningful test names, not just `SpinedBufferTest1`. Also, even more parallelism/timeout room :)

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest1.java line 29:

> 27: 
> 28: import java.util.*;
> 29: //import java.util.function.DoubleConsumer;

These commented out imports should go away.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9845

From alanb at openjdk.org  Fri Aug 19 13:37:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 13:37:36 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected [v4]
In-Reply-To: <er1lVcOiZA8jy08A0y-5-J7uhiV13HSBemw5FpbT-U0=.b3fcec16-9e11-4a45-82c2-e5372f264ee3@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
 <er1lVcOiZA8jy08A0y-5-J7uhiV13HSBemw5FpbT-U0=.b3fcec16-9e11-4a45-82c2-e5372f264ee3@github.com>
Message-ID: <ZrPcGFZc2w2XlXX3vD4QxncvbcgIcvaz62avugY2XBk=.6c682198-55db-48ae-8d36-b9b23b9ec5dc@github.com>

On Thu, 18 Aug 2022 19:29:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Revised test to check and close all of the streams used in the pipeline.
>> 
>> The test now checks the content length and closes each stdout and stderr stream.
>> 
>> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8291760-leaks-close
>  - Revised test to read, check, and close streams from all processes in the pipeline.
>    If any unexpected output is found it is printed.
>  - Merge branch 'master' into 8291760-leaks-close
>  - 8291760: PipelineLeaksFD.java still fails: More or fewer pipes than expected
>    Check the contents and close each stdout and stderr stream.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9905

From ecaspole at openjdk.org  Fri Aug 19 14:25:09 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 19 Aug 2022 14:25:09 GMT
Subject: RFR: 8292623: Reduce runtime of java.io microbenchmarks
Message-ID: <zQoRwZ3PcG7fAJoHQ-8MxHsXlzJjFMYRrAiIVIqhWDA=.95311980-70d7-41d7-ab95-ee4199774aa0@github.com>

These changes reduce the run time from about 3h15m to about 2h5m.

-------------

Commit messages:
 - 8292623: Reduce runtime of java.io microbenchmarks

Changes: https://git.openjdk.org/jdk/pull/9942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292623
  Stats: 44 lines in 10 files changed: 42 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9942.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9942/head:pull/9942

PR: https://git.openjdk.org/jdk/pull/9942

From asemenyuk at openjdk.org  Fri Aug 19 15:49:03 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 19 Aug 2022 15:49:03 GMT
Subject: RFR: 8292316: Tests should not rely on specific JAR file names
 (jpackage)
Message-ID: <xfon_lIF7UKQTh6mJen2ZsC_3THLkGka7iD-pW5sY78=.06ce260f-ab71-4c5f-8010-7074955ba5b8@github.com>

Get rid of dependencies on specific jtreg's jars from jpackage junit tests.

The troublesome statement was `* @library ${jtreg.home}/lib/junit.jar ${jtreg.home}/lib/hamcrest.jar` in "junit.java". The fix removes "junit.java" and the corresponding "run_junit.sh" file and adds jtreg test declarations to each junit test.

-------------

Commit messages:
 - 8292316: Tests should not rely on specific JAR file names (jpackage)

Changes: https://git.openjdk.org/jdk/pull/9944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292316
  Stats: 159 lines in 13 files changed: 63 ins; 84 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9944.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9944/head:pull/9944

PR: https://git.openjdk.org/jdk/pull/9944

From darcy at openjdk.org  Fri Aug 19 15:58:46 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Aug 2022 15:58:46 GMT
Subject: Integrated: JDK-8292576: Improve wording of AccessFlag-related specs
In-Reply-To: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
References: <kCMM-l26JHrkxlYgTxwhUqzeRN9fBok2uubyUTDZYMQ=.9ab08f9e-6636-4207-9624-0e3ed2f4713c@github.com>
Message-ID: <zY1Rp7BJKLW2TsHUNNZdF3dho7q5U5Yp572IxwZJl00=.5be5e3e0-5284-405d-9f24-930a502d7d65@github.com>

On Thu, 18 Aug 2022 05:05:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Spec refinement, including acting on some feedback received for JDK-8266670:
> 
> https://github.com/openjdk/jdk/pull/7445#discussion_r906846794

This pull request has now been integrated.

Changeset: 58aae340
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58aae340a9892889ef8784ef9360bb7e0af85ddd
Stats:     26 lines in 2 files changed: 7 ins; 0 del; 19 mod

8292576: Improve wording of AccessFlag-related specs

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9912

From naoto at openjdk.org  Fri Aug 19 16:40:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Aug 2022 16:40:08 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders like
 UTF-16
Message-ID: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>

Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

-------------

Commit messages:
 - 8292043: Incorrect decoding near EOF for stateful decoders like UTF-16

Changes: https://git.openjdk.org/jdk/pull/9945/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292043
  Stats: 58 lines in 2 files changed: 57 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9945.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9945/head:pull/9945

PR: https://git.openjdk.org/jdk/pull/9945

From duke at openjdk.org  Fri Aug 19 16:57:30 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 Aug 2022 16:57:30 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: <RwohBTjMdBVKeMGzWZWc9uMGlrRkCCSFzIxtv5Wny14=.a8192ea5-eb3b-48af-88d1-4c30c0729595@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <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.

keep open

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From duke at openjdk.org  Fri Aug 19 16:57:34 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 Aug 2022 16:57:34 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v6]
In-Reply-To: <VKdxc6IyKkKUbnjZsUCP8qEfVX87r3x74R8woOq-s8Y=.2d8f4482-36f8-4f19-82dc-a54d4fecdd3d@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <VKdxc6IyKkKUbnjZsUCP8qEfVX87r3x74R8woOq-s8Y=.2d8f4482-36f8-4f19-82dc-a54d4fecdd3d@github.com>
Message-ID: <hUYnvC27f2QPs4msKR4hKrUJfbG7DnbEtru_LJmPhjs=.d762c661-881d-4c79-8afc-7d5996cfb8ab@github.com>

On Wed, 25 May 2022 09:40:42 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279986: methods Math::asXExact for safely checked primitive casts

keep open

-------------

PR: https://git.openjdk.org/jdk/pull/8548

From rriggs at openjdk.org  Fri Aug 19 17:14:29 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Aug 2022 17:14:29 GMT
Subject: RFR: 8276651: java/lang/ProcessHandle/InfoTest.java failed with
 "RuntimeException: Input/output error"
Message-ID: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>

On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.

Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

-------------

Commit messages:
 - 8276651: java/lang/ProcessHandle/InfoTest.java failed with "RuntimeException: Input/output error"

Changes: https://git.openjdk.org/jdk/pull/9946/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8276651
  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9946.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9946/head:pull/9946

PR: https://git.openjdk.org/jdk/pull/9946

From shade at openjdk.org  Fri Aug 19 18:14:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 19 Aug 2022 18:14:16 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Rework timeouts
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Update copyrights
 - Also do Unsafe tests
 - Fix

-------------

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=03
  Stats: 661 lines in 45 files changed: 640 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From dcubed at openjdk.org  Fri Aug 19 19:48:24 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Aug 2022 19:48:24 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms" [v2]
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9844/files
  - new: https://git.openjdk.org/jdk/pull/9844/files/bd9be934..cd61c316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9844&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9844&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9844.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9844/head:pull/9844

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Fri Aug 19 19:55:00 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Aug 2022 19:55:00 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms" [v2]
In-Reply-To: <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
Message-ID: <xmJ7pNwHwoZ-HadPDAJ49k2_tRk6ExRuuB5s2ov__-c=.7dd1a906-3aea-4250-866a-b15c79cdf15d@github.com>

On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor.

Sorry for the delay in getting back to this PR. I've been focused on GateKeeping issues instead.

This latest update:

- Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor.

makes the test happy on my linux-x64 stress runs. My macosx-aarch64 stress runs
are still not happy, but I'm still gathering data on those runs. I haven't found a
COMPILATION_TIMEOUT initial value that works every time yet. The values I've
tried so far:
- 1_000 - the original value in the PR
- 5_000 - the original value in the test before I changed it
- 10_000 - simple doubling
- 20_000 - simple doubling again, testing this value now and thru the weekend

I'm inclined to move ahead with the 5_000 value scaled by timeoutFactor. I think
I need to spend some time to determine why macosx-aarch64 is so much slower
than linux-x64 for this test.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Fri Aug 19 19:56:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Aug 2022 19:56:53 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <Bjs9oBqtc7UBhJ5ryXeH2wLy_H76pFgqLTrT1rkCD24=.9af4035e-9179-49cb-b59b-5864f6b00dd7@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <Bjs9oBqtc7UBhJ5ryXeH2wLy_H76pFgqLTrT1rkCD24=.9af4035e-9179-49cb-b59b-5864f6b00dd7@github.com>
Message-ID: <kNv5vewpwo361uGcgtReg41Eisyer_6eHUvB9l9TCOM=.6101cee4-7a20-4886-9d1b-ce7fb554ccd8@github.com>

On Tue, 16 Aug 2022 16:45:03 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> I would like to propose an alternative separation based on types. We can split into four for refs, ints, longs, and doubles, each extending from the same abstract class with shared code.

@PaulSandoz, @RogerRiggs and @shipilev - Thanks for the reviews. I'll take
a look at splitting the test in a cleaner fashion. I don't write a lot of Java code
so it'll be a little bit before I update again.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Fri Aug 19 19:56:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Aug 2022 19:56:54 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <ZDU4X2CxHWZS6niRYSx8ka4ZBq-c7G59Cx6TZsngGLg=.c4513e16-78c2-4da6-a693-1b3a05c345da@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZDU4X2CxHWZS6niRYSx8ka4ZBq-c7G59Cx6TZsngGLg=.c4513e16-78c2-4da6-a693-1b3a05c345da@github.com>
Message-ID: <nrYCbVVGm1r2mgHhvaRM9qCF8ClbSaRpufBt4CQ-ndA=.14d9ec99-d012-4e25-a537-c3b0471cb1d4@github.com>

On Fri, 19 Aug 2022 12:57:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest1.java line 29:
> 
>> 27: 
>> 28: import java.util.*;
>> 29: //import java.util.function.DoubleConsumer;
> 
> These commented out imports should go away.

Sorry about that. I didn't mean to leave cruft behind.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From joehw at openjdk.org  Fri Aug 19 20:13:49 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Aug 2022 20:13:49 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <qcV4LWGcM9IzQYaLWcBlB2zwzcqZyfMUYXALGrajyV8=.f49a5838-44e1-4c6c-b969-98d2b44a58c6@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9945

From rriggs at openjdk.org  Fri Aug 19 21:06:54 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Aug 2022 21:06:54 GMT
Subject: RFR: 8292623: Reduce runtime of java.io microbenchmarks
In-Reply-To: <zQoRwZ3PcG7fAJoHQ-8MxHsXlzJjFMYRrAiIVIqhWDA=.95311980-70d7-41d7-ab95-ee4199774aa0@github.com>
References: <zQoRwZ3PcG7fAJoHQ-8MxHsXlzJjFMYRrAiIVIqhWDA=.95311980-70d7-41d7-ab95-ee4199774aa0@github.com>
Message-ID: <SONFt4S_YwauITwDvIlQD-rlaAmN493wjYiRAQ9C8vk=.d9dacff1-c522-441f-a3c9-caaf2d6dfb3b@github.com>

On Fri, 19 Aug 2022 14:16:32 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the run time from about 3h15m to about 2h5m.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9942

From almatvee at openjdk.org  Fri Aug 19 22:38:45 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 19 Aug 2022 22:38:45 GMT
Subject: RFR: 8292316: Tests should not rely on specific JAR file names
 (jpackage)
In-Reply-To: <xfon_lIF7UKQTh6mJen2ZsC_3THLkGka7iD-pW5sY78=.06ce260f-ab71-4c5f-8010-7074955ba5b8@github.com>
References: <xfon_lIF7UKQTh6mJen2ZsC_3THLkGka7iD-pW5sY78=.06ce260f-ab71-4c5f-8010-7074955ba5b8@github.com>
Message-ID: <wcp8Zl3M2RSMHDOB2ZHPuw8LSWgU5ECUqQwPP0GkwqI=.2250f6df-95ed-4c9e-8884-cecc9cce73d9@github.com>

On Fri, 19 Aug 2022 15:41:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Get rid of dependencies on specific jtreg's jars from jpackage junit tests.
> 
> The troublesome statement was `* @library ${jtreg.home}/lib/junit.jar ${jtreg.home}/lib/hamcrest.jar` in "junit.java". The fix removes "junit.java" and the corresponding "run_junit.sh" file and adds jtreg test declarations to each junit test.

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9944

From amenkov at openjdk.org  Fri Aug 19 23:21:31 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 19 Aug 2022 23:21:31 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <TrZ_D2g9H4v54x1t4KeoA-OTHI31DTVMf7aFU6sjq2o=.e1f500cc-a526-42a3-8496-166c1c6f687b@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9816

From jiefu at openjdk.org  Fri Aug 19 23:41:30 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 19 Aug 2022 23:41:30 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms" [v2]
In-Reply-To: <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
Message-ID: <6uZlNglz7OlLZfoCmgBwXOBRvwrV0PAG3MDq2MDIWgE=.6e5ac56e-07aa-41e2-a0ad-7797b78c5698@github.com>

On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor.

LGTM

Thanks for the update.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9844

From jpai at openjdk.org  Sat Aug 20 01:52:46 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Aug 2022 01:52:46 GMT
Subject: RFR: 8276651: java/lang/ProcessHandle/InfoTest.java failed with
 "RuntimeException: Input/output error"
In-Reply-To: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
References: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
Message-ID: <II7oA-U5i64ZYGARNqJbZLm5gQvMoYIJ6MdIUsE5o8M=.351d57ee-59b4-4e27-ba3d-0395c8c37745@github.com>

On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.
> 
> Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

Hello Roger,

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.

The `ProcessHandleImpl_unix.c` in its `info0` implementation calls `os_getParentPidAndTimings` and this `os_getCmdlineAndUserInfo`. The  `os_getParentPidAndTimings` in `ProcessHandleImpl_macosx.c` too has a call to `systctl` with the passed `pid` (line 191). If that call fails, we currently don't check the `errno` and just throw a `RuntimeException`. Would that need a change too, since it queries for a particular process?

There's one another call to sysctl in `os_getCmdlineAndUserInfo` at line 253, but that doesn't appear to be specific to the pid, so I guess that wouldn't fail due to the timing of process lifetime.

-------------

PR: https://git.openjdk.org/jdk/pull/9946

From jpai at openjdk.org  Sat Aug 20 02:02:30 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Aug 2022 02:02:30 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <SEjLbNITp0dcxRVQ8zXuhxapMh9F2aS-kfGC1kVRLII=.8edb1b3a-be15-4a3c-9f8f-d01cca115657@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9816

From dcubed at openjdk.org  Sat Aug 20 02:41:32 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 20 Aug 2022 02:41:32 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms"
In-Reply-To: <Hx_PsN6tajqGm81_URYx_CcJEfYHY8WMdrMN_1zOcn4=.4e860bff-214c-4666-b27a-cf531950dd7a@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <Hx_PsN6tajqGm81_URYx_CcJEfYHY8WMdrMN_1zOcn4=.4e860bff-214c-4666-b27a-cf531950dd7a@github.com>
Message-ID: <d3qgV87XtPBuGwtb5sfen1qFmyyuI2qst5UiCaWw-3I=.d7087638-e321-495a-8850-389619e8facd@github.com>

On Fri, 12 Aug 2022 23:44:26 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
>> Definitely not. Traditional default value for no specified timeoutFactor value is 1.0.
> 
> Okay, you're right.
> This is because the timeoutFactor may be used by other tests too.

@DamonFool - Thanks for the re-review!

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Sat Aug 20 02:41:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 20 Aug 2022 02:41:50 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v2]
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <3doNTHOC46Bhx7CNe8tS2GXjTEd6fbmjY_ihIHMPmvQ=.ffd544f2-e2ee-4cf0-95b4-ba1d668a4e77@github.com>

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Refactor SpinedBufferTest.java by type.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9845/files
  - new: https://git.openjdk.org/jdk/pull/9845/files/94513fcd..942e5ffd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9845&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9845&range=00-01

  Stats: 926 lines in 7 files changed: 499 ins; 427 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9845.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9845/head:pull/9845

PR: https://git.openjdk.org/jdk/pull/9845

From stuefe at openjdk.org  Sat Aug 20 07:17:32 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 20 Aug 2022 07:17:32 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10]
In-Reply-To: <Su6vKXkIaDexcGy1PJxoG-6QqSIpqmdTgRlXw7rfJSE=.d30c2586-2009-4f94-86c9-27c954df54ca@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <hWlCDM5VX_bgy-0qoVrZ-y2Fksy1IwzwACLL0pv_ekU=.7e7fa76e-3474-44e7-8271-d0bfe2887979@github.com>
 <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com>
 <uQ3Gn2I3D8Vn7Fk65WNmBIgNjkn321VUIHYPCOZnxHo=.bdb30660-179a-4c1e-bf28-2bf0bb7a1326@github.com>
 <QNtu-cFso7SY28ede-XBVFyllkuyD-yClCdlfb7E6iM=.b363a175-7f25-40bf-b24e-85f342b63d37@github.com>
 <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com>
 <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com>
 <HDqtjDNvH9cs_dKBUk9kzzQhVzf6a2e1c8Zy0b4HNB0=.0a44b091-1199-4d9a-87c5-76a2b9a950b2@github.com>
 <IuwwcnNhvJZZGUWj_hK9fz-x-wsLsDxP87kK2x-afIM=.64698d51-8ce0-49c0-b88e-423e9880510b@github.com>
 <Su6vKXkIaDexcGy1PJxoG-6QqSIpqmdTgRlXw7rfJSE=.d30c2586-2009-4f94-86c9-27c954df54ca@github.com>
Message-ID: <P752wLIe7cZMhpA0ZN9mJF-SDc68Mojsgx47IrXnGRo=.fac7db3c-9f49-41fc-92eb-8d069a22e024@github.com>

On Thu, 18 Aug 2022 15:46:04 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Initially I did intend to do that, but a raw GetLastError wouldn't exactly be very helpful when a failure does occur

I disagree. Error codes are well documented, unlike posix errno with defined numerical values, and often more helpful than the localized error text.

>, and unfortunately formatting the proper message from it takes quite a bit of ceremony (Thanks for nothing Win32 API!) 

Then factor that out into an utility function similar to strerror and use that as input to JLI_ReportErrorMessage. But again, only if it is worth the complexity. As long as there is not a single use case inside libjli we should not add this function.

>that would hopefully be confined to only one function - And it seems so far that this one is quite a suitable candidate. To be sure, that RFE doesn't strictly require this one, and can be changed to use other utilities instead, but as mentioned above the same fault is in Windows error reporting routines all over the JDK, and unlike ReportErrorMessageSys which isn't used that often, those are very commonly used across the codebase, by doing that all we'd be doing is sidestepping the problem and leaving it to be fixed later.

Yes. And that's fine. Please deal with one problem at a time, libjli in this case, and do a clearly defined solution that fits the problem in scope and complexity. Please follow the advice of reviewers, because you burn valuable reviewer time.

> I did hope that a warning or outright refusal to concat the errors when either GetLastError and errno != 0 was a good solution, though

I disagree. It is more confusing and not worth the added complexity. Look at it that way, at one hand you want to resolve errorcode and think raw errcode values are too much for the lay analyst, on the other hand you want to show him two potentially completely unrelated error texts, together with a cryptic warning, and let him figure out what that means? 

Let's do this simple and right. So far I have not seen a single use of this function inside the libjli codebase. So come up with that first as I wrote before. Then, if you see multiple use cases, we can maybe think of unifying code into a helper function. If there are no usages, just remove the function.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From alanb at openjdk.org  Sat Aug 20 08:07:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Aug 2022 08:07:30 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

test/jdk/java/io/InputStreamReader/StatefulDecoderNearEOF.java line 53:

> 51:                     StandardCharsets.UTF_16.newDecoder().onMalformedInput(CodingErrorAction.REPORT))) {
> 52:                 System.out.printf("%04x%n", r.read()); // \u00d8 (wrong, uses UTF-16BE)
> 53:                 System.out.printf("%04x%n", r.read()); // EOF

This will pass if either read fails, I think the test should be checking that the first call to read throws MalformedInputException.

Would it be feasible to add a second test where there are characters between the BOM and the truncated high surrogate? It would be possible to decode those characters before it fails at the end of the stream.

-------------

PR: https://git.openjdk.org/jdk/pull/9945

From aturbanov at openjdk.org  Sat Aug 20 10:08:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 20 Aug 2022 10:08:52 GMT
Subject: Integrated: 8292350: Use static methods for hashCode/toString
 primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <Lru9gwGomh6rLr2cE368n4Z6RopDrctLbqorcYnvw-k=.e1e94fb2-34f4-4dc5-bc86-4106b816920f@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

This pull request has now been integrated.

Changeset: 37c0a136
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37c0a13647e74fd02823a3f621e986f96904b933
Stats:     8 lines in 4 files changed: 0 ins; 0 del; 8 mod

8292350: Use static methods for hashCode/toString primitives

Reviewed-by: prr, rriggs, amenkov, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/9816

From cstein at openjdk.org  Sat Aug 20 16:15:13 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
Message-ID: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>

Please review the change to update to using jtreg 7.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - JDK-8289798: Update to use jtreg 7

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289798
  Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From alanb at openjdk.org  Sat Aug 20 16:15:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <sXUbEwrue0OPm3iF8acsWON7e3Tmtcqk4nF9XgqYmhw=.eb5a6999-aeb7-4605-b324-fbfb0153047f@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Have you run all the tiers to make sure there aren't any issues?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Sat Aug 20 16:15:13 2022
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <oE1p8IenuQxtSD2DphLcuXbGqzMddEmLX1ql7mS7jC0=.4bf15112-af50-4cec-9de6-9cd6205276d3@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

No. I'll mark this PR ready for review when all tiers ran successfully.

Besides the usual bug fixes, updates, and minor improvements (see [changes since jtreg 6.2](https://github.com/openjdk/jtreg/compare/jtreg-6.2+1...jtreg-7+1)) the sole major new feature of jtreg 7 is:
- Run tests annotated with `@run junit` via JUnit Platform's Launcher (version `1.8.2`). This enables writing tests using the Jupiter API (version `5.8.2`) in addition to writing and running JUnit 4-based tests.

The change in `junit.java` will be superseded by https://github.com/openjdk/jdk/pull/9944 which deletes that file.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From jpai at openjdk.org  Sat Aug 20 16:15:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Aug 2022 16:15:13 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <9wOkjC3Cf252C2NCyfb32M5czLcyBK7lqHlKGD_qtaA=.5337fe86-04d6-4e8f-82e5-0e0b074210c3@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hello Christian, more out of curiosity - what are some of the changes that jtreg 7 brings in?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From duke at openjdk.org  Sun Aug 21 06:36:54 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 06:36:54 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
Message-ID: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>

I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.

Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:

public final int readInt() throws IOException {
    int ch1 = in.read();
    int ch2 = in.read();
    int ch3 = in.read();
    int ch4 = in.read();
    if ((ch1 | ch2 | ch3 | ch4) < 0)
        throw new EOFException();
    return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
}

Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.

Benchmarking:

baseline:

Benchmark                     Mode  Cnt   Score   Error  Units
DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op

patch:

Benchmark                     Mode  Cnt   Score   Error  Units
DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

-------------

Commit messages:
 - 8292698: Improve performance of reading from DataInputStream

Changes: https://git.openjdk.org/jdk/pull/9956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292698
  Stats: 85 lines in 2 files changed: 76 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9956/head:pull/9956

PR: https://git.openjdk.org/jdk/pull/9956

From alanb at openjdk.org  Sun Aug 21 07:24:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Aug 2022 07:24:30 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>

On Sun, 21 Aug 2022 06:29:43 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

'in' is a protected field so it requires thinking about subclasses that might change 'in', say when the input stream asynchronously closed. BufferedInputStream is an example of a  FilterInputStream that sets 'in' to null when asynchronously closed. There are other examples that change the underlying input stream to one that returns EOF when closed. So it might be that changing readChar/readInt/readLong is okay but it would have a bigger effect on readFully, skip and the other methods. So I think this is case of proceeding with caution as there may be more gong on.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From fyang at openjdk.org  Sun Aug 21 07:42:22 2022
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 21 Aug 2022 07:42:22 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <mbbdMD4r0cbZZLkZA66Jd8NAgQ-Uu96PSEUh5UzljCk=.299ae531-5d2a-4e9f-bb6a-2a3cc7a935b6@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

The latest changes look good to me. I see all these tests pass stably on my aarch64-linux server.
This wll also improve the case for my riscv64-linux unmatched board: except for VarHandleTestMethodHandleAccess*.java, the other tests could also pass stably now.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9889

From duke at openjdk.org  Sun Aug 21 14:40:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 14:40:25 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v2]
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <cBaPD0dvjSdjWziu0vC3IPI-2xefYrZ6NNUTWytn3sc=.261ce742-cf80-44f9-9277-898580c579ad@github.com>

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8292698: Revert dubious changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9956/files
  - new: https://git.openjdk.org/jdk/pull/9956/files/31a9c451..a2378ded

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9956/head:pull/9956

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Sun Aug 21 14:40:27 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 14:40:27 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <26yiaoNsz5OrPiDNbckXWfTBy0SM-6ZLaYci1KOG1T8=.2ffcfa81-5373-40f6-8d46-452998d2a3df@github.com>

On Sun, 21 Aug 2022 06:29:43 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

I've revert dubious changes

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Sun Aug 21 15:13:12 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 15:13:12 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <_s3sF9jqz1Y0MQgdRZhGtR-tw5SWD31kE9qc0VLVPu4=.b7288078-0987-422d-8dbf-08b3231c60b4@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Anyone to sponsor?

-------------

PR: https://git.openjdk.org/jdk/pull/9513

From duke at openjdk.org  Sun Aug 21 17:26:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 17:26:25 GMT
Subject: Integrated: 8290300: Use standard String-joining tools where
 applicable
In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
Message-ID: <svnuj6nwuqYSwv8UKIS1dmTsPaOiLVcc3Bq496Iwb1k=.0a3c92b1-ee46-47ea-932b-71407fd5096f@github.com>

On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Simplify code with `String.join()`

This pull request has now been integrated.

Changeset: 9a65524e
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a65524e2f98c1b4e253dcb637a708cec7b591bc
Stats:     18 lines in 4 files changed: 0 ins; 12 del; 6 mod

8290300: Use standard String-joining tools where applicable

Reviewed-by: naoto, rriggs, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/9513

From duke at openjdk.org  Sun Aug 21 18:48:29 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 18:48:29 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <BCU12FIOG4jTD6ccnV1_RxyBvCcQAdqjq_CsekHDvr8=.8500dbee-3869-4ca6-bae4-274f7a658763@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/9513

From duke at openjdk.org  Sun Aug 21 20:07:10 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 20:07:10 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8292698: Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9956/files
  - new: https://git.openjdk.org/jdk/pull/9956/files/a2378ded..1535e925

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9956/head:pull/9956

PR: https://git.openjdk.org/jdk/pull/9956

From lbourges at openjdk.org  Sun Aug 21 20:23:53 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 21 Aug 2022 20:23:53 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v16]
In-Reply-To: <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
Message-ID: <-k-NoJQwXp04AMia76vkzZtDup97cP77Y7ADy1ai3d8=.9e18e522-a21c-4ba0-bc31-c2f7c41ca5a7@github.com>

On Tue, 2 Aug 2022 13:57:03 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)
>   
>   * Optimized and unified buffer allocation
>   * Minor comment changes

Here are the full results published on my github:

https://github.com/bourgesl/bourgesl.github.io/tree/master/jdk-jmh-arraysort

Tested on latest openjdk/jdk (08.20).

Direct vizualiser:
https://jmh.morethan.io/?sources=https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/full/openjdk20-master-jmh-result.json,https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/full/openjdk20-patched-jmh-result.json

Such visualization is really nice!

I will run tests in microseconds, longer and down-clock my cpu to have more stable results on small array lengths (100-1000).

Laurent

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From naoto at openjdk.org  Sun Aug 21 23:19:16 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sun, 21 Aug 2022 23:19:16 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Modified the test per review suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9945/files
  - new: https://git.openjdk.org/jdk/pull/9945/files/24977db2..09846f00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9945&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9945&range=00-01

  Stats: 36 lines in 1 file changed: 22 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9945.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9945/head:pull/9945

PR: https://git.openjdk.org/jdk/pull/9945

From naoto at openjdk.org  Sun Aug 21 23:19:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sun, 21 Aug 2022 23:19:19 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>
Message-ID: <A1CPW8JBx-qkDWILTFRcd52ZeBeenr98enjWGAwrwTo=.e700247b-4588-46fe-add6-e40ff7a79ccc@github.com>

On Sat, 20 Aug 2022 08:03:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified the test per review suggestion
>
> test/jdk/java/io/InputStreamReader/StatefulDecoderNearEOF.java line 53:
> 
>> 51:                     StandardCharsets.UTF_16.newDecoder().onMalformedInput(CodingErrorAction.REPORT))) {
>> 52:                 System.out.printf("%04x%n", r.read()); // \u00d8 (wrong, uses UTF-16BE)
>> 53:                 System.out.printf("%04x%n", r.read()); // EOF
> 
> This will pass if either read fails, I think the test should be checking that the first call to read throws MalformedInputException.
> 
> Would it be feasible to add a second test where there are characters between the BOM and the truncated high surrogate? It would be possible to decode those characters before it fails at the end of the stream.

Addressed both points.

-------------

PR: https://git.openjdk.org/jdk/pull/9945

From xgong at openjdk.org  Mon Aug 22 01:37:20 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 22 Aug 2022 01:37:20 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <9yLjZcGBbRtdXeL3NiyO8IoTW7SJ315Z1Zra1JB5uyE=.9bd541c7-a5fd-4857-8e12-8062a87cfbe5@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
 <_fGPajWNCtuXnHfcwopnUFrSkcCngdWEfKOrHbgfsZY=.cd497659-247f-41f9-afad-f8f72cd23811@github.com>
 <PnuaR1w_is-cf38fQvXTnnPwgyv3GKrfh8Sy-N0NC1M=.118c4a4d-3082-43f5-83b4-0dcb8e3eb0d1@github.com>
 <9yLjZcGBbRtdXeL3NiyO8IoTW7SJ315Z1Zra1JB5uyE=.9bd541c7-a5fd-4857-8e12-8062a87cfbe5@github.com>
Message-ID: <qapQ1rm1W8T9SGtncGKXOhZVdKGaCX9VxMHR3DtZbFs=.80d382c2-4c15-4bdf-b4d1-f1838049d1ea@github.com>

On Wed, 17 Aug 2022 15:16:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Looks good.
>> 
>> Thanks for looking at this patch @PaulSandoz ! 
>> 
>>> Much better to flip the operation and the receiver + first arg to the blend.
>> 
>> I'm not quite understand what the flip operation here mean. The current code is simple enough to me. Could you please show more details? Thanks a lot!
>
>> > Much better to flip the operation and the receiver + first arg to the blend.
>> 
>> I'm not quite understand what the flip operation here mean. The current code is simple enough to me. Could you please show more details? Thanks a lot!
> 
> I mean to say your approach is much better: changing `ne` to `eq` and changing the arguments to the blend.

Hi @PaulSandoz , may I get an approve from your side? Thanks so much!

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From alanb at openjdk.org  Mon Aug 22 06:43:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Aug 2022 06:43:25 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
Message-ID: <-TSDa6wxWKjU4NIdKueApRv16V3IeRSpEFKaoWSlPDY=.00334da1-e546-4371-a469-3b58fc0a8124@github.com>

On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the test per review suggestion

Thanks for the update, I think the test is much better now.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9945

From asotona at openjdk.org  Mon Aug 22 07:12:13 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 22 Aug 2022 07:12:13 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3]
In-Reply-To: <VsOakaQ5sci1hIJiQW3VVSJ_ilqzRlaPltMvQtpGJLQ=.c2707403-9280-48fd-8a98-22c8bf9da8af@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <D4wAQ1eHUnHYZsRzjjYwCIsdKpHeOugdKrNwxYh4Ufs=.fe14d73a-fde9-4e91-a8d1-214edde05a63@github.com>
 <xX9VDTF0NGm2tyiU3o6VZf9BYbhsbyxNMhK0No9k_O8=.7c6104e9-b31d-4f4d-b6b2-7b70a75f1827@github.com>
 <VsOakaQ5sci1hIJiQW3VVSJ_ilqzRlaPltMvQtpGJLQ=.c2707403-9280-48fd-8a98-22c8bf9da8af@github.com>
Message-ID: <0r0lBXlrzHKZQbQrQxsFZQ2t2B57yGpcqaygfiM7R_c=.6967dc09-ea8b-452e-bbad-468f649b7f3d@github.com>

On Tue, 26 Jul 2022 19:57:38 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 85:
>> 
>>> 83:      * given the name of the class or interface in internal form,
>>> 84:      * such as {@code "java/lang/String"}.
>>> 85:      * (To create a descriptor for an array type, either use {@link #ofDescriptor(String)}
>> 
>> It feels like this section could be expanded a bit (and parenthesis removed). E.g. as you point out in the comment, this method only supports reference types, so we should state so clearly. And then present alternatives (like you do now).
>
> Isn?t the?internal?name of?an?array?type its?descriptor?though?
> 
> So, I?feel?like this?method should?allow array?descriptors.

First may I ask which parenthesis should be removed?

Mentioning "reference" is misleading when talking about Class internal name (JVMS 4.2.1 "Binary Class and Interface Names"). Word "reference" is mentioned in (JVMS 4.3.2. "Field Descriptors", Table 4.3-A. "Interpretation of field descriptors") and it also includes array types descriptors, so it might be rather mentioned in ClassDesc::ofDescriptor method doc.

This is also answer to the second comment - field descriptor of array type isn't an internal name according to my understanding of JVMS.
This method suppose to construct ClassDesc from class or interface internal name according to JVMS 4.2.1.
Construction of ClassDesc from field descriptor according to JVMS 4.3.2 is ClassDesc::ofDescriptor method responsibility.

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From asotona at openjdk.org  Mon Aug 22 07:27:25 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 22 Aug 2022 07:27:25 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3]
In-Reply-To: <xX9VDTF0NGm2tyiU3o6VZf9BYbhsbyxNMhK0No9k_O8=.7c6104e9-b31d-4f4d-b6b2-7b70a75f1827@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <D4wAQ1eHUnHYZsRzjjYwCIsdKpHeOugdKrNwxYh4Ufs=.fe14d73a-fde9-4e91-a8d1-214edde05a63@github.com>
 <xX9VDTF0NGm2tyiU3o6VZf9BYbhsbyxNMhK0No9k_O8=.7c6104e9-b31d-4f4d-b6b2-7b70a75f1827@github.com>
Message-ID: <_YwivDpNpN7dcsjgID8QfbfjbXgVrdJ6AoP_aRPVzuk=.62231086-0981-4f81-9096-8ffe835f08c1@github.com>

On Tue, 26 Jul 2022 09:25: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:
>> 
>>   updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation
>
> test/jdk/java/lang/constant/ClassDescTest.java line 268:
> 
>> 266:         }
>> 267: 
>> 268:         List<String> badInternalNames = List.of("I;", "[]",
> 
> is `[]` a good test for arrays? Wouldn't something more realistic like `[Ljava/lang/String` be better? I note that `[]` is also used in another test. Problem with testing `[]` is that if the checking logic has a bug, or a regression is introduced so that it only detects `]` instead of `[` the test would not detect that (but I guess that's a remote possibility).

Thanks for pointing it out, I'll add a valid array descriptor into the list of badInternalNames.

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From asotona at openjdk.org  Mon Aug 22 07:40:34 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 22 Aug 2022 07:40:34 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v4]
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <iIwtmbQKJGmdzyrGfgbh96RofOR91vg4EHfaPXNkCdY=.7f668192-e1e7-46a0-9b30-01eedb00de4d@github.com>

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  extended ClassDescTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9201/files
  - new: https://git.openjdk.org/jdk/pull/9201/files/9cb30fbf..f422b655

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

PR: https://git.openjdk.org/jdk/pull/9201

From shade at openjdk.org  Mon Aug 22 07:45:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 07:45:38 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v2]
In-Reply-To: <3doNTHOC46Bhx7CNe8tS2GXjTEd6fbmjY_ihIHMPmvQ=.ffd544f2-e2ee-4cf0-95b4-ba1d668a4e77@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <3doNTHOC46Bhx7CNe8tS2GXjTEd6fbmjY_ihIHMPmvQ=.ffd544f2-e2ee-4cf0-95b4-ba1d668a4e77@github.com>
Message-ID: <exXXKwb7VgYFTeGLyDK40wCPWjJAxF2QZwCPx_7M468=.2c01f3ee-bcbe-4e33-b85e-752d52af0900@github.com>

On Sat, 20 Aug 2022 02:41:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor SpinedBufferTest.java by type.

Looks much better, I have only a few Java stylistic nits.

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 27:

> 25: import java.util.*;
> 26: 
> 27: public class SpinedBufferTestCommon {

Usually done like this:

Suggestion:

public abstract class AbstractSpinedBufferTest {

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 30:

> 28: 
> 29:     // Create sizes around the boundary of spines
> 30:     static List<Integer> sizes;

Pre-existing, but code style:

Suggestion:

    static final List<Integer> SIZES;

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 43:

> 41:         catch (Exception e) {
> 42:             e.printStackTrace();
> 43:         }

The usual way to terminate the clinit "cleanly" is:

Suggestion:

        } catch (Exception e) {
            throw new IllegalStateException(e);
        }


This allows you to `final` out the `SIZES` field, as dataflow would definitely show the class initialization fails if field init did not happen.

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestDouble.java line 35:

> 33: 
> 34: @Test
> 35: public class SpinedBufferTestDouble extends SpinedBufferTestCommon {

Here and later, I think the common naming convention is having the "Test" at the end, i.e.:

Suggestion:

public class SpinedBufferDoubleTest extends SpinedBufferTestCommon {

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestDouble.java line 36:

> 34: @Test
> 35: public class SpinedBufferTestDouble extends SpinedBufferTestCommon {
> 36:     // DoubleSpinedBuffer

Unnecessary comment, I think?

test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestInt.java line 94:

> 92:         PrimitiveIterator.OfInt it = sb.iterator();
> 93:         for (int i = 0; i < TEST_SIZE; i++)
> 94:             list2.add(it.nextInt());

Pre-existing? Here and later, let's keep the braces on:

Suggestion:

        for (int i = 0; i < TEST_SIZE; i++) {
            list2.add(it.nextInt());
        }

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From kasperni at gmail.com  Mon Aug 22 09:17:48 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 22 Aug 2022 10:17:48 +0100
Subject: Inconsistency between ClassDesc::packageName and Class::getPackageName
Message-ID: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>

Hi,

I was playing around with java.lang.constant and found an inconsistency between
ClassDesc::packageName and Class::getPackageName as outlined in the table below.
Specifically dealing with primitive and array types.

Class       ClassDesc::packageName Class::getPackage Class::getPackageName
 ---------- ---------------------- ----------------- ---------------------
  int        ""                     null              "java.lang"
  int[]      ""                     null              "java.lang"
  Integer    "java.lang"            java.lang         "java.lang"
  Integer[]  ""                     null              "java.lang"

I was originally going to submit a patch for ClassDesc. But I now think
Class::getPackageName is the one that I need to patch. Thoughts?

Thanks,
  Kasper

From ihse at openjdk.org  Mon Aug 22 09:46:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Aug 2022 09:46:29 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <pjZuqauBESo1K8V4r6qdA6QH5dTgTPW7SXXRo-HupZg=.8c05fc7c-ad31-4448-a792-3f99cfe01e69@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

I think the configure script should verify that we got the minimum jtreg needed. This is not really related to the change, but seeing this PR got me thinking about it. I also think a change such as this might bite people who have local setups with older jtreg installations, and then it would be nice for it to fail early in configure.

If you are interested in including such a check, I could contribute the code for the configure script.

I just want to check one thing: I see there are multiple `requiredVersion` in different TEST.ROOT files. Does this new requirement apply to *all* our jtreg tests?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From shade at openjdk.org  Mon Aug 22 09:49:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 09:49:35 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <l0lC7nP8wnyT8Rn9Q0gBX-tgEtHORIGHF1zVRSbjxcc=.14fbfe70-eaec-4562-ae60-630a2c9c0670@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

Yes, so I have reworked this to please more machines. I have clean run on RPi 4 (AArch64), and semi-clean run on HiFive Unmatched board (there are still some timeouts, but no weak failures). I believe the `VarHandleTestMethodHandleAccess` are slow themselves, and pairing them with a very slow board would run into problems. I'll look into speeding up `VarHandles` tests even more in separate PR.

If anyone is interested how this PR behaves on their platforms, feel free to test it! Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From vkempik at openjdk.org  Mon Aug 22 09:56:29 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Mon, 22 Aug 2022 09:56:29 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <4a6gc0KNY47xvY_Mxj_KR9a0EzezPoT4sJ3cDsgtNNY=.bf089ebf-8c50-4059-b8d5-bbcb8ff61354@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

Same result as @RealFYang 's, VarHandleTestAccessShort.java is ok now
VarHandleTestMethodHandleAccess*.java time out

-------------

Marked as reviewed by vkempik (Committer).

PR: https://git.openjdk.org/jdk/pull/9889

From lancea at openjdk.org  Mon Aug 22 10:30:28 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 22 Aug 2022 10:30:28 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
Message-ID: <WiCraSqHGYa7lJ9SMxP2QFYPYuay_HOuQg99CZFZ3rQ=.a43dd658-9342-4ac2-bdbb-1ca78eeceef1@github.com>

On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the test per review suggestion

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9945

From ihse at openjdk.org  Mon Aug 22 11:36:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Aug 2022 11:36:31 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <84r0tcH3qGIH6INXsFU0NSEe1cpkrs4SucSnj5WNtkA=.f02c5997-449c-4302-aaaa-ae3a4b5b3c02@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Actually, lets do that separately. I opened https://bugs.openjdk.org/browse/JDK-8292716.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From shade at openjdk.org  Mon Aug 22 12:53:29 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 12:53:29 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <MgEEqFuRSLQCGZiCJdVx5UlVpl7S0gB2HmVGRNslKVk=.796d67b7-ad43-422a-ac20-5944429887b4@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

@PaulSandoz -- want to take a look?

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From mdoerr at openjdk.org  Mon Aug 22 13:14:32 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Aug 2022 13:14:32 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <iVmdjomLGovCE2vtOhEEylLren5AP3pLJHwLG5qb4NU=.346c8381-8959-4375-a1d8-3d0fae83ee76@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

In general, I appreciate making these tests more resilient.
However, I wonder about such large numbers for retry attempts. Smells like more than just sporadic failures. Are we sure there is no bug which causes more failures? Does it really make sense to have a weak implementation on platforms with such high failure rates?

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From shade at openjdk.org  Mon Aug 22 13:40:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 13:40:28 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <iVmdjomLGovCE2vtOhEEylLren5AP3pLJHwLG5qb4NU=.346c8381-8959-4375-a1d8-3d0fae83ee76@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <iVmdjomLGovCE2vtOhEEylLren5AP3pLJHwLG5qb4NU=.346c8381-8959-4375-a1d8-3d0fae83ee76@github.com>
Message-ID: <KcTPNnSQIku62GQjr5-ySTs_fOkwFQgXtGPOE-cZHCk=.e08ce634-f91f-44ea-95f8-47e9e0a1fa4b@github.com>

On Mon, 22 Aug 2022 13:12:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> In general, I appreciate making these tests more resilient. However, I wonder about such large numbers for retry attempts. Smells like more than just sporadic failures. Are we sure there is no bug which causes more failures? Does it really make sense to have a weak implementation on platforms with such high failure rates?

I suspect we are dealing with the accidental cache line sharing, or context switching, or cache capacity limits that "break" LL/SC weak implementations. Backoff and more retries seems to help to pull ourselves out of this mess.

As the alternative, we can provide the whitelist of platforms where weak CAS is guaranteed to succeed. (We need to dig through if, for example, AArch64 LSE atomics provide more resilient progress behavior.) That would, unfortunately, stop to verify that some LL/SC implementations _ever_ succeed.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From ecaspole at openjdk.org  Mon Aug 22 13:44:30 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Mon, 22 Aug 2022 13:44:30 GMT
Subject: Integrated: 8292623: Reduce runtime of java.io microbenchmarks
In-Reply-To: <zQoRwZ3PcG7fAJoHQ-8MxHsXlzJjFMYRrAiIVIqhWDA=.95311980-70d7-41d7-ab95-ee4199774aa0@github.com>
References: <zQoRwZ3PcG7fAJoHQ-8MxHsXlzJjFMYRrAiIVIqhWDA=.95311980-70d7-41d7-ab95-ee4199774aa0@github.com>
Message-ID: <NAzz2wtuRyIr_gUImjc6chECYbLBbq991TPCAwLUICM=.68b5d1d1-6bb6-4c34-84a2-d5b138bcd003@github.com>

On Fri, 19 Aug 2022 14:16:32 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These changes reduce the run time from about 3h15m to about 2h5m.

This pull request has now been integrated.

Changeset: e5619339
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e561933907bbab0a42f1796fa12f582b3a347312
Stats:     44 lines in 10 files changed: 42 ins; 0 del; 2 mod

8292623: Reduce runtime of java.io microbenchmarks

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9942

From asemenyuk at openjdk.org  Mon Aug 22 15:46:43 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 22 Aug 2022 15:46:43 GMT
Subject: Integrated: 8292316: Tests should not rely on specific JAR file names
 (jpackage)
In-Reply-To: <xfon_lIF7UKQTh6mJen2ZsC_3THLkGka7iD-pW5sY78=.06ce260f-ab71-4c5f-8010-7074955ba5b8@github.com>
References: <xfon_lIF7UKQTh6mJen2ZsC_3THLkGka7iD-pW5sY78=.06ce260f-ab71-4c5f-8010-7074955ba5b8@github.com>
Message-ID: <SEbfWOQx6tf9JhbmOd-wgmHjWsfNo82N0OJrt7fzMxM=.1aa78457-74e4-460b-bd26-876a38656045@github.com>

On Fri, 19 Aug 2022 15:41:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Get rid of dependencies on specific jtreg's jars from jpackage junit tests.
> 
> The troublesome statement was `* @library ${jtreg.home}/lib/junit.jar ${jtreg.home}/lib/hamcrest.jar` in "junit.java". The fix removes "junit.java" and the corresponding "run_junit.sh" file and adds jtreg test declarations to each junit test.

This pull request has now been integrated.

Changeset: 45c3e898
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45c3e898ed538545921395372fe507e9111401e1
Stats:     159 lines in 13 files changed: 63 ins; 84 del; 12 mod

8292316: Tests should not rely on specific JAR file names (jpackage)

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/9944

From psandoz at openjdk.org  Mon Aug 22 15:51:31 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 22 Aug 2022 15:51:31 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <lgj5pPyzVhnvwxurzPPnEMIlJMoJryAEKcxl4g99vcU=.15a58b56-0d69-4b99-9da6-7ad23ca41f19@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From naoto at openjdk.org  Mon Aug 22 16:31:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Aug 2022 16:31:39 GMT
Subject: Integrated: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <-hDH22W2z2dk5_dOkW2kyaxffPe7LVeCVsg_ZXXsD6s=.d59f068d-0bf6-480b-9d83-f13053640b83@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

This pull request has now been integrated.

Changeset: aa9b8f04
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa9b8f04bf74d5fa00f2b27895e7369abea3a930
Stats:     80 lines in 2 files changed: 79 ins; 1 del; 0 mod

8292043: Incorrect decoding near EOF for stateful decoders like UTF-16

Reviewed-by: joehw, alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/9945

From cstein at openjdk.org  Mon Aug 22 16:39:17 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 22 Aug 2022 16:39:17 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v2]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <8gFr6V8k4vF-3cJt34Vp_6F-MtOb2TyMwJNjhgUveoU=.535be13e-459c-4cd3-8bca-5eb66587a084@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - JDK-8289798: Update to use jtreg 7

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=01
  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From joe.darcy at oracle.com  Mon Aug 22 16:46:29 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Aug 2022 09:46:29 -0700
Subject: Inconsistency between ClassDesc::packageName and
 Class::getPackageName
In-Reply-To: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>
References: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>
Message-ID: <b4d16e4e-ab39-a107-b3d6-9a862d3a1e4e@oracle.com>

Hello,

The method Class.getPackage is behaving as specified:

> public Package getPackage()
> Gets the package of this class.
>
> If this class represents an array type, a primitive type or void, this 
> method returns null.

as is Class.getPackageName():

> If this class represents an array type then this method returns the 
> package name of the element type. If this class represents a primitive 
> type or void then the package name "|java.lang|" is returned.

and ClassDesc.packageName is as well.

Class.getPackage has been doing what it been doing since about JDK 1.2 
so due to behavioral compatibility, there would have to be a much 
stronger case for altering its behavior at this point.

-Joe

On 8/22/2022 2:17 AM, Kasper Nielsen wrote:
> Hi,
>
> I was playing around with java.lang.constant and found an inconsistency between
> ClassDesc::packageName and Class::getPackageName as outlined in the table below.
> Specifically dealing with primitive and array types.
>
> Class       ClassDesc::packageName Class::getPackage Class::getPackageName
>   ---------- ---------------------- ----------------- ---------------------
>    int        ""                     null              "java.lang"
>    int[]      ""                     null              "java.lang"
>    Integer    "java.lang"            java.lang         "java.lang"
>    Integer[]  ""                     null              "java.lang"
>
> I was originally going to submit a patch for ClassDesc. But I now think
> Class::getPackageName is the one that I need to patch. Thoughts?
>
> Thanks,
>    Kasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220822/6c642f84/attachment-0001.htm>

From mdoerr at openjdk.org  Mon Aug 22 16:53:08 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Aug 2022 16:53:08 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <KcTPNnSQIku62GQjr5-ySTs_fOkwFQgXtGPOE-cZHCk=.e08ce634-f91f-44ea-95f8-47e9e0a1fa4b@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <iVmdjomLGovCE2vtOhEEylLren5AP3pLJHwLG5qb4NU=.346c8381-8959-4375-a1d8-3d0fae83ee76@github.com>
 <KcTPNnSQIku62GQjr5-ySTs_fOkwFQgXtGPOE-cZHCk=.e08ce634-f91f-44ea-95f8-47e9e0a1fa4b@github.com>
Message-ID: <v1Qbk3MDhzS67xD7gEnTrS-suFdJ7ghSKO9xXs6amPk=.10c93600-d835-44de-b364-064d987189a1@github.com>

On Mon, 22 Aug 2022 13:36:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > In general, I appreciate making these tests more resilient. However, I wonder about such large numbers for retry attempts. Smells like more than just sporadic failures. Are we sure there is no bug which causes more failures? Does it really make sense to have a weak implementation on platforms with such high failure rates?
> 
> I suspect we are dealing with the accidental cache line sharing, or context switching, or cache capacity limits that "break" LL/SC weak implementations. Backoff and more retries seems to help to pull ourselves out of this mess.
> 
> As the alternative, we can provide the whitelist of platforms where weak CAS is guaranteed to succeed. (We need to dig through if, for example, AArch64 LSE atomics provide more resilient progress behavior.) That would, unfortunately, stop to verify that some LL/SC implementations _ever_ succeed.

My concern is that we may not notice implementation problems any more when retrying so often. Accidental cache line sharing should better get fixed in the tests if possible. Context switching or cache capacity limits may cause 1 failure, not 100. What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From shade at openjdk.org  Mon Aug 22 17:10:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 17:10:38 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <v1Qbk3MDhzS67xD7gEnTrS-suFdJ7ghSKO9xXs6amPk=.10c93600-d835-44de-b364-064d987189a1@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <iVmdjomLGovCE2vtOhEEylLren5AP3pLJHwLG5qb4NU=.346c8381-8959-4375-a1d8-3d0fae83ee76@github.com>
 <KcTPNnSQIku62GQjr5-ySTs_fOkwFQgXtGPOE-cZHCk=.e08ce634-f91f-44ea-95f8-47e9e0a1fa4b@github.com>
 <v1Qbk3MDhzS67xD7gEnTrS-suFdJ7ghSKO9xXs6amPk=.10c93600-d835-44de-b364-064d987189a1@github.com>
Message-ID: <yAAKvKioTyPUKwYe7RnskOOmnx-aZZy2ZQgpapUj6HU=.8ebe032e-0c41-4df7-a743-536c25704d1b@github.com>

On Mon, 22 Aug 2022 16:49:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> My concern is that we may not notice implementation problems any more when retrying so often. Accidental cache line sharing should better get fixed in the tests if possible. Context switching or cache capacity limits may cause 1 failure, not 100. What do you think?

I would not dare to say that 100 retries is going to be enough for everything; I don't even dare to say that is "too many", my test experiments ran with tens of thousands retries before.

Here is a thing, though: for weak LL/SC hardware, we would enter the same kind (but unbounded!) retry loop inside strong CAS implementation. If the implementation is laggy, we would spin there a lot. In fact, I don't think anyone actually measured how much retries we need to succeed at strong CAS on such platforms. But as long as such CAS eventually succeeds, it looks to be a performance question, not the functionality one. The tests affected by this PR are testing the functional part: weak CAS _eventually_ succeeds after aggressive retries/backoffs.

The failing platforms I have (RISC-V) are remarkably slow to dissect what might be going on there. We can dive there, for sure, but I reckon that would take weeks to resolve. It can wait, if you feel strongly about it.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From kasperni at gmail.com  Mon Aug 22 17:13:17 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 22 Aug 2022 18:13:17 +0100
Subject: Inconsistency between ClassDesc::packageName and
 Class::getPackageName
In-Reply-To: <b4d16e4e-ab39-a107-b3d6-9a862d3a1e4e@oracle.com>
References: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>
 <b4d16e4e-ab39-a107-b3d6-9a862d3a1e4e@oracle.com>
Message-ID: <CAPs6152bQK8gJg0Czn71a4wtr7vK7WE2TWv2Prbdt7UEbEKy=w@mail.gmail.com>

Hi,

I understand that the methods are behaving as specified.
However, I still think that

int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""

is surprising behavior. And should probably as a minimum be
documented on ClassDesc::packageName.

/Kasper

On Mon, 22 Aug 2022 at 17:46, Joe Darcy <joe.darcy at oracle.com> wrote:
>
> Hello,
>
> The method Class.getPackage is behaving as specified:
>
> public Package getPackage()
> Gets the package of this class.
>
> If this class represents an array type, a primitive type or void, this method returns null.
>
> as is Class.getPackageName():
>
> If this class represents an array type then this method returns the package name of the element type. If this class represents a primitive type or void then the package name "java.lang" is returned.
>
> and ClassDesc.packageName is as well.
>
> Class.getPackage has been doing what it been doing since about JDK 1.2 so due to behavioral compatibility, there would have to be a much stronger case for altering its behavior at this point.
>
> -Joe
>
> On 8/22/2022 2:17 AM, Kasper Nielsen wrote:
>
> Hi,
>
> I was playing around with java.lang.constant and found an inconsistency between
> ClassDesc::packageName and Class::getPackageName as outlined in the table below.
> Specifically dealing with primitive and array types.
>
> Class       ClassDesc::packageName Class::getPackage Class::getPackageName
>  ---------- ---------------------- ----------------- ---------------------
>   int        ""                     null              "java.lang"
>   int[]      ""                     null              "java.lang"
>   Integer    "java.lang"            java.lang         "java.lang"
>   Integer[]  ""                     null              "java.lang"
>
> I was originally going to submit a patch for ClassDesc. But I now think
> Class::getPackageName is the one that I need to patch. Thoughts?
>
> Thanks,
>   Kasper

From dcubed at openjdk.org  Mon Aug 22 15:33:24 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 15:33:24 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v2]
In-Reply-To: <exXXKwb7VgYFTeGLyDK40wCPWjJAxF2QZwCPx_7M468=.2c01f3ee-bcbe-4e33-b85e-752d52af0900@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <3doNTHOC46Bhx7CNe8tS2GXjTEd6fbmjY_ihIHMPmvQ=.ffd544f2-e2ee-4cf0-95b4-ba1d668a4e77@github.com>
 <exXXKwb7VgYFTeGLyDK40wCPWjJAxF2QZwCPx_7M468=.2c01f3ee-bcbe-4e33-b85e-752d52af0900@github.com>
Message-ID: <mDuy_n5fcUaXkkjSCB45y88Hb6OyTna9h2IGqLmbjX8=.76f72e6e-b4c4-46a4-b5b3-d0d27fed1418@github.com>

On Mon, 22 Aug 2022 07:42:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor SpinedBufferTest.java by type.
>
> Looks much better, I have only a few Java stylistic nits.

@shipilev - Thanks for the re-review! You did so before I even asked for one. :-)
I'll go thru your comments above.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Mon Aug 22 17:46:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 17:46:48 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v2]
In-Reply-To: <exXXKwb7VgYFTeGLyDK40wCPWjJAxF2QZwCPx_7M468=.2c01f3ee-bcbe-4e33-b85e-752d52af0900@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <3doNTHOC46Bhx7CNe8tS2GXjTEd6fbmjY_ihIHMPmvQ=.ffd544f2-e2ee-4cf0-95b4-ba1d668a4e77@github.com>
 <exXXKwb7VgYFTeGLyDK40wCPWjJAxF2QZwCPx_7M468=.2c01f3ee-bcbe-4e33-b85e-752d52af0900@github.com>
Message-ID: <w3Pem3Eu_kgHBtnceprrAcUiGfcZd3SODcb5qqpFyik=.24b82eef-24ad-4af9-bcca-814847e11425@github.com>

On Mon, 22 Aug 2022 07:35:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor SpinedBufferTest.java by type.
>
> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 27:
> 
>> 25: import java.util.*;
>> 26: 
>> 27: public class SpinedBufferTestCommon {
> 
> Usually done like this:
> 
> Suggestion:
> 
> public abstract class AbstractSpinedBufferTest {

fixed

> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 30:
> 
>> 28: 
>> 29:     // Create sizes around the boundary of spines
>> 30:     static List<Integer> sizes;
> 
> Pre-existing, but code style:
> 
> Suggestion:
> 
>     static final List<Integer> SIZES;

fixed even though it is pre-existing.

> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestCommon.java line 43:
> 
>> 41:         catch (Exception e) {
>> 42:             e.printStackTrace();
>> 43:         }
> 
> The usual way to terminate the clinit "cleanly" is:
> 
> Suggestion:
> 
>         } catch (Exception e) {
>             throw new IllegalStateException(e);
>         }
> 
> 
> This allows you to `final` out the `SIZES` field, as dataflow would definitely show the class initialization fails if field init did not happen.

fixed

> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestDouble.java line 35:
> 
>> 33: 
>> 34: @Test
>> 35: public class SpinedBufferTestDouble extends SpinedBufferTestCommon {
> 
> Here and later, I think the common naming convention is having the "Test" at the end, i.e.:
> 
> Suggestion:
> 
> public class SpinedBufferDoubleTest extends SpinedBufferTestCommon {

fixed here and the other tests also.

> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestDouble.java line 36:
> 
>> 34: @Test
>> 35: public class SpinedBufferTestDouble extends SpinedBufferTestCommon {
>> 36:     // DoubleSpinedBuffer
> 
> Unnecessary comment, I think?

fixed here and the other tests also.

> test/jdk/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTestInt.java line 94:
> 
>> 92:         PrimitiveIterator.OfInt it = sb.iterator();
>> 93:         for (int i = 0; i < TEST_SIZE; i++)
>> 94:             list2.add(it.nextInt());
> 
> Pre-existing? Here and later, let's keep the braces on:
> 
> Suggestion:
> 
>         for (int i = 0; i < TEST_SIZE; i++) {
>             list2.add(it.nextInt());
>         }

fixed here and in other tests even though it is pre-existing.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From psandoz at openjdk.org  Mon Aug 22 17:46:53 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 22 Aug 2022 17:46:53 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <bHeg5aBjvQxuSvi1UjQBmXG-r_taV6pn53xN08Mx3yo=.665f36d3-f656-468d-904a-5f9f04dde8ca@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

It's awkward to manage this across various hardware, esp. if the hardware is less mature (perhaps combined with a less mature HotSpot implementation). The approach looks reasonable, but it would be nice if we could just increase the retries and waiting values on weak LL/SC hardware or at least follow up with something like that later on.

As a quick experiment could we annotate fields with `@Contended` and see if that reduces the number of retries?

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From dcubed at openjdk.org  Mon Aug 22 18:03:21 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 18:03:21 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  shipilev CR changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9845/files
  - new: https://git.openjdk.org/jdk/pull/9845/files/942e5ffd..946c7cf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9845&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9845&range=01-02

  Stats: 44 lines in 5 files changed: 12 ins; 8 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/9845.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9845/head:pull/9845

PR: https://git.openjdk.org/jdk/pull/9845

From shade at openjdk.org  Mon Aug 22 18:08:32 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Aug 2022 18:08:32 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
Message-ID: <ggVW-A5IEH-0jUN9LxYbcj7y52k_9bt4F8F4rX-m8UY=.b2e25f96-0819-4149-be4d-848aae6abd88@github.com>

On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shipilev CR changes

I am good with this version, thanks.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Mon Aug 22 18:14:15 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 18:14:15 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <ggVW-A5IEH-0jUN9LxYbcj7y52k_9bt4F8F4rX-m8UY=.b2e25f96-0819-4149-be4d-848aae6abd88@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
 <ggVW-A5IEH-0jUN9LxYbcj7y52k_9bt4F8F4rX-m8UY=.b2e25f96-0819-4149-be4d-848aae6abd88@github.com>
Message-ID: <PLZCESoda6PO4CHdoX23PPoD3rz26vK-IXuPUQRRQQI=.b97678fe-d13d-43e3-80fe-9eb5b7909a90@github.com>

On Mon, 22 Aug 2022 18:04:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   shipilev CR changes
>
> I am good with this version, thanks.

@shipilev - Thanks for the very fast re-review. I've tested this version on
my MBP13. Doing another Mach5 Tier1 with all the other patches in this
batch just as a sanity check.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From rriggs at openjdk.org  Mon Aug 22 18:44:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Aug 2022 18:44:24 GMT
Subject: RFR: 8276651: java/lang/ProcessHandle/InfoTest.java failed with
 "RuntimeException: Input/output error"
In-Reply-To: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
References: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
Message-ID: <thblnAFev3amQNTOviKKD2oYRm9KCi52CtpElzm5SE0=.5476208a-584f-4408-b83f-a5f419ad5b1f@github.com>

On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.
> 
> Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

The failing tests don't implicate the sysctl at 191 so I'm cautious about changing the code in that case.
The spec for `ProcessHandle.info()` does not declare any exceptions so there is little risk changing the behavior by quietly returning in the case of EINVAL or EIO to make the cases similar when querying a pid.

-------------

PR: https://git.openjdk.org/jdk/pull/9946

From Alan.Bateman at oracle.com  Mon Aug 22 18:57:05 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Aug 2022 19:57:05 +0100
Subject: Inconsistency between ClassDesc::packageName and
 Class::getPackageName
In-Reply-To: <CAPs6152bQK8gJg0Czn71a4wtr7vK7WE2TWv2Prbdt7UEbEKy=w@mail.gmail.com>
References: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>
 <b4d16e4e-ab39-a107-b3d6-9a862d3a1e4e@oracle.com>
 <CAPs6152bQK8gJg0Czn71a4wtr7vK7WE2TWv2Prbdt7UEbEKy=w@mail.gmail.com>
Message-ID: <9fab5598-9c86-5fbd-3374-8eb67914437d@oracle.com>

On 22/08/2022 18:13, Kasper Nielsen wrote:
> Hi,
>
> I understand that the methods are behaving as specified.
> However, I still think that
>
> int.class.getPackageName() = "java.lang"
> int.class.describeConstable().get().packageName() = ""
>
> is surprising behavior. And should probably as a minimum be
> documented on ClassDesc::packageName.
>
A named module is a set of named packages and it just wouldn't work for 
a class in a named module to say that it's in the unnamed package. As I 
recall, the original proposal for getPackageName was that it return null 
when the class is for an array or primitive class but that turned out to 
be a usability issue. The proposal was refined to what is specified now.

ClassDesc is a nominal descriptor so it's more like parsing a string to 
get the package name. I don't disagree that the packageName method could 
link to isArray and componentType when the descriptor is for an array 
type, or isPrimitive to test if the descriptor is for a primitive type.

-Alan.

From rriggs at openjdk.org  Mon Aug 22 19:03:32 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Aug 2022 19:03:32 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
Message-ID: <_uBr9gKJXhjru5GM5JaF0spzxRnrfKlUvaD_mCi5kFc=.32b66e19-815b-4b7b-b7f2-c531aaa0d56a@github.com>

On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shipilev CR changes

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Mon Aug 22 19:09:27 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 19:09:27 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <_uBr9gKJXhjru5GM5JaF0spzxRnrfKlUvaD_mCi5kFc=.32b66e19-815b-4b7b-b7f2-c531aaa0d56a@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
 <_uBr9gKJXhjru5GM5JaF0spzxRnrfKlUvaD_mCi5kFc=.32b66e19-815b-4b7b-b7f2-c531aaa0d56a@github.com>
Message-ID: <TDtf-POyiPSK6JmJd5nVv7SdrrcUphqDskYsZVHOwLE=.ad6e106d-ab7d-4c1c-8bdb-b42be58f7339@github.com>

On Mon, 22 Aug 2022 18:59:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   shipilev CR changes
>
> LGTM

@RogerRiggs - Thanks for the re-review!

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Mon Aug 22 19:34:00 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 19:34:00 GMT
Subject: Integrated: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed
 with "AssertionError: Failed to compile int Fuzz.com_int(int,int) in 5000ms"
In-Reply-To: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
Message-ID: <-M9CPtkTo04P-ZKA9V74TNRQY8XZZnaX41JlBGYzMqI=.4d6c3620-5827-4e1a-8736-2b28795960cc@github.com>

On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
> when waiting for a compilation to finish.
> 
> This fix is being tested in my jdk-20+10 stress testing run.
> 
> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.

This pull request has now been integrated.

Changeset: 54843b70
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54843b700a463e75cd23a23df8ec5dc73b80f105
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8290211: jdk/internal/vm/Continuation/Fuzz.java failed with "AssertionError: Failed to compile int Fuzz.com_int(int,int) in 5000ms"

Reviewed-by: lmesnik, alanb, jiefu

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Mon Aug 22 19:34:57 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 19:34:57 GMT
Subject: Integrated: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug
In-Reply-To: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
Message-ID: <k8c471OQ4u411qqTgloxJ7W5NsbXz9wsljUMeLoVkkY=.a1cb9b5a-e5f7-4183-a332-d3988a5503cb@github.com>

On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
> 
> I couldn't figure out a way to set a larger timeout value for the entirety
> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
> this problem with testng tests by splitting the test into more parts.
> 
> This fix is being tested in my jdk-20+10 stress testing run.

This pull request has now been integrated.

Changeset: ab698859
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab6988599cded028ebfc4c958bc9e88d1b365ad7
Stats:     873 lines in 6 files changed: 503 ins; 370 del; 0 mod

8292215: java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java times out with slowdebug

Reviewed-by: rriggs, shade

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From dcubed at openjdk.org  Mon Aug 22 19:48:45 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 19:48:45 GMT
Subject: RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with
 "AssertionError: Failed to compile int Fuzz.com_int(int,
 int) in 5000ms" [v2]
In-Reply-To: <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
References: <1kI_VCLlBGLrZ4dNRK8DyudZ0eGj-LSwFS4KZCh6dOU=.20a41732-8993-43b6-adc7-f4da2cba07c6@github.com>
 <6ScJvWgoXh9VVE1ECtzAkhJiea3MXEwhFLgHtVR2Lec=.65b96ec4-8ab9-4f3c-850d-5f1f26c1c22c@github.com>
Message-ID: <JIuQLlsNjGwrvUqlhpgbsituiBjlB8MmHJDbvg84li4=.f3cd8560-e3f8-4c1c-acf1-993f0a61b8fc@github.com>

On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG setting
>> when waiting for a compilation to finish.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>> 
>> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a timeoutFactor
>> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 and slowdebug-bits: 12.0.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor.

jdk/internal/vm/Continuation/Fuzz.java* passed 12 times (2 sub-tests x 6 configs)
in two different Mach5 Tier1 job sets.

-------------

PR: https://git.openjdk.org/jdk/pull/9844

From dcubed at openjdk.org  Mon Aug 22 19:52:37 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 22 Aug 2022 19:52:37 GMT
Subject: RFR: 8292215:
 java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
 times out with slowdebug [v3]
In-Reply-To: <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
References: <Ln_QTr5MMQqU_15MbsU2EkcJt-FJhB408KHibgpHjxk=.6c741159-6a20-4254-bd3e-226a183e70a5@github.com>
 <ZJ6wO8AlBQxtqSsCL_txlQqj8V4qlOfZYeJADeGoAzo=.6a006244-42a2-4488-bc02-c7a0af534135@github.com>
Message-ID: <DxUj9qI5ea4POwcjXEhx6pkFxeAECGVXWLYlO-QxYGY=.da5ab864-b0ee-4792-a548-3668ca22367a@github.com>

On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>> 
>> I couldn't figure out a way to set a larger timeout value for the entirety
>> of java/util/stream/SpinedBufferTest.java and I saw that other folks solved
>> this problem with testng tests by splitting the test into more parts.
>> 
>> This fix is being tested in my jdk-20+10 stress testing run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shipilev CR changes

java/util/stream/boottest/java.base/java/util/stream/*SpinedBuffer* passed 30 times (5 tests x 6 configs)
in each of two different Mach5 Tier1 job sets.

-------------

PR: https://git.openjdk.org/jdk/pull/9845

From joe.darcy at oracle.com  Mon Aug 22 20:09:03 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 22 Aug 2022 13:09:03 -0700
Subject: Inconsistency between ClassDesc::packageName and
 Class::getPackageName
In-Reply-To: <9fab5598-9c86-5fbd-3374-8eb67914437d@oracle.com>
References: <CAPs6150rFoZmCQOmY21-04+zyFwzH=9=cLtM4yHYsXTUgEDyng@mail.gmail.com>
 <b4d16e4e-ab39-a107-b3d6-9a862d3a1e4e@oracle.com>
 <CAPs6152bQK8gJg0Czn71a4wtr7vK7WE2TWv2Prbdt7UEbEKy=w@mail.gmail.com>
 <9fab5598-9c86-5fbd-3374-8eb67914437d@oracle.com>
Message-ID: <8828b38e-a391-0a8c-2edd-40922adceb01@oracle.com>

On 8/22/2022 11:57 AM, Alan Bateman wrote:
> On 22/08/2022 18:13, Kasper Nielsen wrote:
>> Hi,
>>
>> I understand that the methods are behaving as specified.
>> However, I still think that
>>
>> int.class.getPackageName() = "java.lang"
>> int.class.describeConstable().get().packageName() = ""
>>
>> is surprising behavior. And should probably as a minimum be
>> documented on ClassDesc::packageName.
>>
> A named module is a set of named packages and it just wouldn't work 
> for a class in a named module to say that it's in the unnamed package. 
> As I recall, the original proposal for getPackageName was that it 
> return null when the class is for an array or primitive class but that 
> turned out to be a usability issue. The proposal was refined to what 
> is specified now.
>
> ClassDesc is a nominal descriptor so it's more like parsing a string 
> to get the package name. I don't disagree that the packageName method 
> could link to isArray and componentType when the descriptor is for an 
> array type, or isPrimitive to test if the descriptor is for a 
> primitive type.


I agree it would be fine to add apiNote/@see/@link tags, etc. , but 
don't think any behavior change is justified.

-Joe


From jpai at openjdk.org  Tue Aug 23 00:31:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Aug 2022 00:31:44 GMT
Subject: RFR: 8276651: java/lang/ProcessHandle/InfoTest.java failed with
 "RuntimeException: Input/output error"
In-Reply-To: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
References: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
Message-ID: <ZIxk7qHIVTb-2KSbb39hJebW7xfZWJSFnXgJjOukolY=.861dbfab-e8e1-4608-a69a-d0d05383fb5e@github.com>

On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.
> 
> Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

Marked as reviewed by jpai (Reviewer).

Thank you for that detail, Roger. The change looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/9946

From rriggs at openjdk.org  Tue Aug 23 00:59:21 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 Aug 2022 00:59:21 GMT
Subject: RFR: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected [v5]
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <7d24gyxasmGtumTcA1UI1Z3WUnmZADoZlyUaRYuQkvI=.a416c3aa-a0dd-4574-9ed7-55f2ee0f9108@github.com>

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct loop termination to include the streams of the last Process

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9905/files
  - new: https://git.openjdk.org/jdk/pull/9905/files/d3354444..f015a10e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9905&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9905&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9905/head:pull/9905

PR: https://git.openjdk.org/jdk/pull/9905

From xgong at openjdk.org  Tue Aug 23 01:30:33 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 23 Aug 2022 01:30:33 GMT
Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise
 FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <vVUQvY4S1mBPOrs_v4tstgqmsM1AMZeWLthL4mXftps=.03836efb-048c-405e-b2ba-30baa1751f1d@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

Thanks for the review Paul!

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From xgong at openjdk.org  Tue Aug 23 01:33:02 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 23 Aug 2022 01:33:02 GMT
Subject: Integrated: 8291118: [vectorapi] Optimize the implementation of
 lanewise FIRST_NONZERO
In-Reply-To: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
References: <P8hLdPQIkfc-KCvD6qNfwaKDiVVDIihmZTkUDI4CvHk=.4f622af3-72d6-41e6-ac5f-97e25465a2f7@github.com>
Message-ID: <Rp9iFS-p9kgrL-AzLIRt4uOAhNQOVCrsJWACSxys5FM=.6ad532ec-bae0-4e07-9ac4-bb5da55a3fd3@github.com>

On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is:
> 
> 
> 1) mask = a.compare(0, ne);
> 2) b = b.blend(0, mask);
> 3) result = a | b;
> 
> 
> And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types.
> 
> A simpler implementation is:
> 
> 
> 1) mask = a.compare(0, eq);
> 2) result = a.blend(b, mask);
> 
> 
> This could save the final "`OR`" operation and the related reinterpretation between FP and integral types.
> 
> Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system:
> 
> Benchmark                          (size) Mode  Cnt  Before    After    Units
> ByteMaxVector.FIRST_NONZERO         1024  thrpt  15 12107.422 18385.157 ops/ms
> ByteMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  9765.282 14739.775 ops/ms
> DoubleMaxVector.FIRST_NONZERO       1024  thrpt  15  1798.545  2331.214 ops/ms
> DoubleMaxVector.FIRST_NONZEROMasked 1024  thrpt  15  1211.838  1810.644 ops/ms
> FloatMaxVector.FIRST_NONZERO        1024  thrpt  15  3491.924  4377.167 ops/ms
> FloatMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  2307.085  3606.576 ops/ms
> IntMaxVector.FIRST_NONZERO          1024  thrpt  15  3602.727  5610.258 ops/ms
> IntMaxVector.FIRST_NONZEROMasked    1024  thrpt  15  2726.843  4210.741 ops/ms
> LongMaxVector.FIRST_NONZERO         1024  thrpt  15  1819.886  2974.655 ops/ms
> LongMaxVector.FIRST_NONZEROMasked   1024  thrpt  15  1337.737  2315.094 ops/ms
> ShortMaxVector.FIRST_NONZERO        1024  thrpt  15  6603.642  9586.320 ops/ms
> ShortMaxVector.FIRST_NONZEROMasked  1024  thrpt  15  5222.006  7991.443 ops/ms
> 
> We can also observe the similar improvement on x86 system.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266

This pull request has now been integrated.

Changeset: 4da17458
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4da1745836550224306ca66201c35a5baaf30953
Stats:     86 lines in 7 files changed: 9 ins; 38 del; 39 mod

8291118: [vectorapi] Optimize the implementation of lanewise FIRST_NONZERO

Reviewed-by: eliu, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/9683

From shade at openjdk.org  Tue Aug 23 06:55:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Aug 2022 06:55:38 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <8kSLUOmLzkmkdn-kqgrQdwpZfZJCxN3uBATId3XXHQk=.b920384c-7ad0-45dd-8d16-7a02b078e5b5@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

I have found the related RISC-V issue that makes the tests very slow -- https://github.com/openjdk/jdk/pull/9970 -- I think we should let that one first, and then reconsider what backoffs we do here. Looks to me with that patch, HiFive Unmatched is fine with 1ms backoff delay, not 100ms as this PR proposes.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From cstein at openjdk.org  Tue Aug 23 07:56:03 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 07:56:03 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v3]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <NPKRpVVHDHwfB2kvOc_MTp6sHVt5Mu4FVZm_GAV7Z4c=.de6bf26c-a53e-4eba-a57c-72de78c1cecf@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update github-actions.conf
 - ... and 1 more: https://git.openjdk.org/jdk/compare/486f90c1...468f0bd3

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02
  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Tue Aug 23 07:58:20 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 07:58:20 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v4]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <20AQsJGMltW6Z6Ml-SDdXFJ81F83MnHmCl524jLvECA=.5f72fc0c-e973-45d1-92e4-e3f383d727ad@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update configure to check for jtreg 7 or later

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9393/files
  - new: https://git.openjdk.org/jdk/pull/9393/files/468f0bd3..1f6f4a7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From mdoerr at openjdk.org  Tue Aug 23 08:38:25 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 23 Aug 2022 08:38:25 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
Message-ID: <QDm1sKWeFGqK4PfR73giCJWL6RLdSvT8iAe0ZojFWOc=.6b34a891-e62e-4c3c-b242-7e7c15c3cc92@github.com>

On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - Also do Unsafe tests
>  - Fix

Excellent! Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From cstein at openjdk.org  Tue Aug 23 11:22:55 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Aug 2022 11:22:55 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>

> Please review the change to update to using jtreg 7.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update configure to check for jtreg 7 or later
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

-------------

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=04
  Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

PR: https://git.openjdk.org/jdk/pull/9393

From alanb at openjdk.org  Tue Aug 23 12:38:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Aug 2022 12:38:19 GMT
Subject: RFR: 8276651: java/lang/ProcessHandle/InfoTest.java failed with
 "RuntimeException: Input/output error"
In-Reply-To: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
References: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
Message-ID: <-oalIhxgxgO8KWHonwc5S9lM1YndM3CI5e8VzZlXXjA=.e95dd0bf-0fa6-47d6-ad92-a675615ac465@github.com>

On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.
> 
> Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9946

From dfuchs at openjdk.org  Tue Aug 23 14:01:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 Aug 2022 14:01:32 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
Message-ID: <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>

On Sun, 21 Aug 2022 07:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 'in' is a protected field so it requires thinking about subclasses that might change 'in', say when the input stream is asynchronously closed. BufferedInputStream is an example of a FilterInputStream that sets 'in' to null when asynchronously closed. There are other examples that change the underlying input stream to one that returns EOF when closed. So it might be that changing readChar/readInt/readLong is okay but it would have a bigger effect on readFully, skip and the other methods. So I think this is a case of proceeding with caution as there may be more gong on.

On the other hand I don't see anything checking for `in == null`, so if `in` was null a `NullPointerException` exception would occur, which I doubt is the behavior that the subclass is expecting. I agree that caution is warranted, but if `in` is actually set to `null` by subclasses we should probably double check how/when they rely in their super class behavior: some bugs might be lurking.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Tue Aug 23 14:35:34 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 23 Aug 2022 14:35:34 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
Message-ID: <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>

On Tue, 23 Aug 2022 13:57:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I agree that caution is warranted

But assuming I've reverted the changes that are dubious, how could there be bugs caused by replacement of multiple reads with a single one? I was sure that such replacement improves thread safety as soon as we rid racy reads.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From rriggs at openjdk.org  Tue Aug 23 14:39:58 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 Aug 2022 14:39:58 GMT
Subject: Integrated: 8276651: java/lang/ProcessHandle tests fail with
 "RuntimeException: Input/output error" in
 java.lang.ProcessHandleImpl$Info.info0
In-Reply-To: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
References: <ULl3GxlIqinCFyxonbckud7ZgD5SiqeRZPj2AU29s7U=.9d3aeb16-4321-4bc4-be4e-bfe15f64d45e@github.com>
Message-ID: <JdamyVjthd04s5xgsRcr-NwBUQwrIUQ5JdJD_bn_ZQg=.bab50f0f-03ec-4692-b16a-921610f1cc90@github.com>

On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid) can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL, leaving the information to be returned empty.
> 
> Several tests in java/lang/ProcessHandle failed with the same cause including OnExitTest, InfoTest, and TreeTest.

This pull request has now been integrated.

Changeset: d24b7b70
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d24b7b7026cf85f1aecf44f60819762872cfd5c1
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8276651: java/lang/ProcessHandle tests fail with "RuntimeException: Input/output error" in java.lang.ProcessHandleImpl$Info.info0

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9946

From dfuchs at openjdk.org  Tue Aug 23 15:55:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 Aug 2022 15:55:33 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
 <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
Message-ID: <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>

On Tue, 23 Aug 2022 14:31:26 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> > I agree that caution is warranted
> 
> But assuming I've reverted the changes that are dubious, how could there be bugs caused by replacement of multiple reads with a single one? I was sure that such replacement improves thread safety as soon as we rid racy reads.

Yes - that's what I was trying to say. I believe reading the volatile only once per method is much better for consistency. And I'm not sure I see why the other changes were dubious since these methods weren't checking for `null` either?
My point is that if some method in the subclass can set the value to `null` asynchronously when some other method in the super class is running then that's a NPE time-bomb (and IMO there's a bug lurking if that can happen).

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From shade at openjdk.org  Tue Aug 23 16:25:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Aug 2022 16:25:11 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v5]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <5KtWMM1iHbm9sP_kXNvTvsYHav-om5WS3pklrW8vxrc=.5a15db4f-a3d1-4fc0-aa14-97334b1463bd@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Pull Handles.get out of the weak retry loop
 - Drop weakDelay to 1
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Rework timeouts
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Update copyrights
 - Also do Unsafe tests
 - Fix

-------------

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=04
  Stats: 951 lines in 45 files changed: 800 ins; 0 del; 151 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From alanb at openjdk.org  Tue Aug 23 17:16:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Aug 2022 17:16:36 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
 <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
 <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>
Message-ID: <MWh3QsYVk4f3NTTJ851ScGPNHWx7LqQ1pkDyDqnHBho=.a87df293-ce45-4244-bfda-b930d82af48e@github.com>

On Tue, 23 Aug 2022 15:50:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> But assuming I've reverted the changes that are dubious, how could there be bugs caused by replacement of multiple reads with a single one? I was sure that such replacement improves thread safety as soon as we rid racy reads.

The main thing is to think through the implications for async close where the close method replaces 'in'. There are a few examples in the JDK that extend FilterInputStream that do this. It was hard to reason about this scenario in the first iteration.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Tue Aug 23 19:00:32 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 23 Aug 2022 19:00:32 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <MWh3QsYVk4f3NTTJ851ScGPNHWx7LqQ1pkDyDqnHBho=.a87df293-ce45-4244-bfda-b930d82af48e@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
 <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
 <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>
 <MWh3QsYVk4f3NTTJ851ScGPNHWx7LqQ1pkDyDqnHBho=.a87df293-ce45-4244-bfda-b930d82af48e@github.com>
Message-ID: <9qZ0-uMZWC06EkfnUPXXIF9ejxxw0RbCW1ZvTq0PxMU=.11e0a143-aa8a-47cb-9592-96510f1c8bc7@github.com>

On Tue, 23 Aug 2022 17:12:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The main thing is to think through the implications for async close where the close method replaces 'in'.

Suppose we have a scenario where `in` is replaced asynchronously in one of implementations and the implementation is passed into constructor of `DataInputStream`. In this case the patched code is less NPE-vulnerable, isn't it?

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From ihse at openjdk.org  Tue Aug 23 19:00:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Aug 2022 19:00:38 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <MMwEFrKFcaeMSW8w40l9U-UxdtcyHKFMO0Lh9L9k6AI=.f0ec8801-9b38-430a-a62c-b1d90d16fb86@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From naoto at openjdk.org  Tue Aug 23 22:54:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Aug 2022 22:54:12 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
Message-ID: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>

This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

-------------

Commit messages:
 - 8291660: Grapheme support in BreakIterator
 - 8291660: Add a method to stream extended grapheme clusters in a String

Changes: https://git.openjdk.org/jdk/pull/9991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291660
  Stats: 251 lines in 10 files changed: 170 ins; 48 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

PR: https://git.openjdk.org/jdk/pull/9991

From ethan at mccue.dev  Tue Aug 23 23:49:23 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 23 Aug 2022 19:49:23 -0400
Subject: Proposal: Collection mutability marker interfaces
Message-ID: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>

Hi all,

I am running into an issue with the collections framework where I have to
choose between good semantics for users and performance.

Specifically I am taking a java.util.List from my users and I need to
choose to either
* Not defensively copy and expose a potential footgun when I pass that List
to another thread
* Defensively copy and make my users pay an unnecessary runtime cost.

What I would really want, in a nutshell, is for List.copyOf to be a no-op
when used on lists made with List.of().

Below the line is a pitch I wrote up on reddit 7 months ago for a mechanism
I think could accomplish that. My goal is to share the idea a bit more
widely and to this specific audience to get feedback.

https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3


Important also for context is Ron Pressler's comment above.
--------------

What if the collections api added more marker interfaces like RandomAccess?

It's already a common thing for codebases to make explicit null checks at
error boundaries because the type system can't encode null | List<String>.

This feels like a similar problem.
If you have a List<T> in the type system then you don't know for sure you
can call any methods on it until you check that its not null. In the same
way, there is a set of methods that you don't know at the type/interface
level if you are allowed to call.

If the List is actually a __
Then you can definitely call
And you know other reference holders might call
And you can confirm its this case by
null
no methods
no methods
list == null
List.of(...)
get, size
get, size
???
Collections.unmodifiableList(...)
get, size
get, size, add, set
???
Arrays.asList(...)
get, size, set
get, size, set
???
new ArrayList<>()
get, size, add, set
get, size, add, set
???
While yes, there is no feasible way to encode these things in the type
system. Its not impossible to encode it at runtime though.
interface FullyImmutable {
// So you know the existence of this implies the absence
// of the others
default Void cantIntersect() { return null; }
}

interace MutationCapability {
default String cantIntersect() { return ""; }
}

interface Addable extends MutationCapability {}
interface Settable extends MutationCapability {}

If the List is actually a __
Then you can definitely call
And you know other reference holders might call
And you can confirm its this case by
null
no methods
no methods
list == null
List.of(...)
get, size
get, size
instanceof FullyImmutable
Collections.unmodifiableList(...)
get, size
get, size, add, set
!(instanceof Addable) && !(instanceof Settable)
Arrays.asList(...)
get, size, set
get, size, set
instanceof Settable
new ArrayList<>()
get, size, add, set
get, size, add, set
instanceof Settable && instanceof Addable
In the same way a RandomAccess check let's implementations decide whether
they want to try an alternative algorithm or crash, some marker
"capability" interfaces would let users of a collection decide if they want
to clone what they are given before working on it.


--------------

So the applicability of this would be that the list returned by List.of
could implement FullyImmutable, signifying that there is no caller which
might have a mutable handle on the collection. Then List.of could check for
this interface and skip a copy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220823/b4018928/attachment-0001.htm>

From paul.sandoz at oracle.com  Wed Aug 24 01:00:17 2022
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 24 Aug 2022 01:00:17 +0000
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
Message-ID: <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>

List.copyOf already does what you want.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168

Paul.

> On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
> 
> Hi all,
> 
> I am running into an issue with the collections framework where I have to choose between good semantics for users and performance.
> 
> Specifically I am taking a java.util.List from my users and I need to choose to either
> * Not defensively copy and expose a potential footgun when I pass that List to another thread
> * Defensively copy and make my users pay an unnecessary runtime cost.
> 
> What I would really want, in a nutshell, is for List.copyOf to be a no-op when used on lists made with List.of().
> 
> Below the line is a pitch I wrote up on reddit 7 months ago for a mechanism I think could accomplish that. My goal is to share the idea a bit more widely and to this specific audience to get feedback.
> 
> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3 
> 
> Important also for context is Ron Pressler's comment above.
> --------------
> 
> What if the collections api added more marker interfaces like RandomAccess?
> 
> It's already a common thing for codebases to make explicit null checks at error boundaries because the type system can't encode null | List<String>. 
> 
> This feels like a similar problem.
> If you have a List<T> in the type system then you don't know for sure you can call any methods on it until you check that its not null. In the same way, there is a set of methods that you don't know at the type/interface level if you are allowed to call.
> 
> If the List is actually a __
> Then you can definitely call
> And you know other reference holders might call
> And you can confirm its this case by
> null
> no methods
> no methods
> list == null
> List.of(...)
> get, size
> get, size
> ???
> Collections.unmodifiableList(...)
> get, size
> get, size, add, set
> ???
> Arrays.asList(...)
> get, size, set
> get, size, set
> ???
> new ArrayList<>()
> get, size, add, set
> get, size, add, set
> ???
> While yes, there is no feasible way to encode these things in the type system. Its not impossible to encode it at runtime though.
> interface FullyImmutable {
> // So you know the existence of this implies the absence
> // of the others
> default Void cantIntersect() { return null; }
> }
> 
> interace MutationCapability {
> default String cantIntersect() { return ""; }
> }
> 
> interface Addable extends MutationCapability {}
> interface Settable extends MutationCapability {}
> 
> If the List is actually a __
> Then you can definitely call
> And you know other reference holders might call
> And you can confirm its this case by
> null
> no methods
> no methods
> list == null
> List.of(...)
> get, size
> get, size
> instanceof FullyImmutable
> Collections.unmodifiableList(...)
> get, size
> get, size, add, set
> !(instanceof Addable) && !(instanceof Settable)
> Arrays.asList(...)
> get, size, set
> get, size, set
> instanceof Settable
> new ArrayList<>()
> get, size, add, set
> get, size, add, set
> instanceof Settable && instanceof Addable
> In the same way a RandomAccess check let's implementations decide whether they want to try an alternative algorithm or crash, some marker "capability" interfaces would let users of a collection decide if they want to clone what they are given before working on it.
> 
> 
> --------------
> 
> So the applicability of this would be that the list returned by List.of could implement FullyImmutable, signifying that there is no caller which might have a mutable handle on the collection. Then List.of could check for this interface and skip a copy.
> 
> 


From ethan at mccue.dev  Wed Aug 24 01:24:41 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 23 Aug 2022 21:24:41 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
Message-ID: <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>

Ah, I'm an idiot.

There is still a proposal here somewhere...maybe. right now non jdk lists
can't participate in the special casing?

On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> List.copyOf already does what you want.
>
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>
> Paul.
>
> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
> >
> > Hi all,
> >
> > I am running into an issue with the collections framework where I have
> to choose between good semantics for users and performance.
> >
> > Specifically I am taking a java.util.List from my users and I need to
> choose to either
> > * Not defensively copy and expose a potential footgun when I pass that
> List to another thread
> > * Defensively copy and make my users pay an unnecessary runtime cost.
> >
> > What I would really want, in a nutshell, is for List.copyOf to be a
> no-op when used on lists made with List.of().
> >
> > Below the line is a pitch I wrote up on reddit 7 months ago for a
> mechanism I think could accomplish that. My goal is to share the idea a bit
> more widely and to this specific audience to get feedback.
> >
> >
> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
> >
> > Important also for context is Ron Pressler's comment above.
> > --------------
> >
> > What if the collections api added more marker interfaces like
> RandomAccess?
> >
> > It's already a common thing for codebases to make explicit null checks
> at error boundaries because the type system can't encode null |
> List<String>.
> >
> > This feels like a similar problem.
> > If you have a List<T> in the type system then you don't know for sure
> you can call any methods on it until you check that its not null. In the
> same way, there is a set of methods that you don't know at the
> type/interface level if you are allowed to call.
> >
> > If the List is actually a __
> > Then you can definitely call
> > And you know other reference holders might call
> > And you can confirm its this case by
> > null
> > no methods
> > no methods
> > list == null
> > List.of(...)
> > get, size
> > get, size
> > ???
> > Collections.unmodifiableList(...)
> > get, size
> > get, size, add, set
> > ???
> > Arrays.asList(...)
> > get, size, set
> > get, size, set
> > ???
> > new ArrayList<>()
> > get, size, add, set
> > get, size, add, set
> > ???
> > While yes, there is no feasible way to encode these things in the type
> system. Its not impossible to encode it at runtime though.
> > interface FullyImmutable {
> > // So you know the existence of this implies the absence
> > // of the others
> > default Void cantIntersect() { return null; }
> > }
> >
> > interace MutationCapability {
> > default String cantIntersect() { return ""; }
> > }
> >
> > interface Addable extends MutationCapability {}
> > interface Settable extends MutationCapability {}
> >
> > If the List is actually a __
> > Then you can definitely call
> > And you know other reference holders might call
> > And you can confirm its this case by
> > null
> > no methods
> > no methods
> > list == null
> > List.of(...)
> > get, size
> > get, size
> > instanceof FullyImmutable
> > Collections.unmodifiableList(...)
> > get, size
> > get, size, add, set
> > !(instanceof Addable) && !(instanceof Settable)
> > Arrays.asList(...)
> > get, size, set
> > get, size, set
> > instanceof Settable
> > new ArrayList<>()
> > get, size, add, set
> > get, size, add, set
> > instanceof Settable && instanceof Addable
> > In the same way a RandomAccess check let's implementations decide
> whether they want to try an alternative algorithm or crash, some marker
> "capability" interfaces would let users of a collection decide if they want
> to clone what they are given before working on it.
> >
> >
> > --------------
> >
> > So the applicability of this would be that the list returned by List.of
> could implement FullyImmutable, signifying that there is no caller which
> might have a mutable handle on the collection. Then List.of could check for
> this interface and skip a copy.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220823/c6586e1d/attachment-0001.htm>

From duke at openjdk.org  Wed Aug 24 04:52:49 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 24 Aug 2022 04:52:49 GMT
Subject: RFR: 8288933: Improve the implementation of
 Double/Float.isInfinite
In-Reply-To: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
References: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
Message-ID: <cj2mswgRAwLVYosTv-X4qRoeLY3qcyVtNcpHHp26R3Y=.6c663633-e9af-42ac-9ba8-fc9f2cace34e@github.com>

On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm).
> 
> `test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here:
> 
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
> 
> Thank you very much.

May I have a review for this patch, please? Thanks a lot.

-------------

PR: https://git.openjdk.org/jdk/pull/9238

From jolyjdia at gmail.com  Fri Aug 19 10:49:54 2022
From: jolyjdia at gmail.com (Zelva Lia)
Date: Fri, 19 Aug 2022 13:49:54 +0300
Subject: CopyOnWriteArrayList Collection.shuffle
Message-ID: <CAMETwp7LCVBLxfo25r7aqQ_X8vXjOOf5t=u5uG5X9EJ0a9O+cA@mail.gmail.com>

Hello, when shuffling the CopyOnWrite list with the standard
Collections.shuffle method, performance anomalies occur, due to the fact
that it calls the set method, which copies the array each time, a possible
solution (crutch) is a random comparator for sorting, so sorting in COW is
redefined to its own sub - blocking implementation

Another problem with Collections.shuffle is that it's not exactly thread
safe because it calls the size() method; and then iterates from it, also
COW does not support modification inside the iterator (works on snapshots)


COWCollectionsShuffle      0,008 ops/ms
COWListRandomSort         1,089 ops/ms
syncListCollectionsShuffle  0,950 ops/ms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220819/cc786ff4/attachment.htm>

From alanb at openjdk.org  Wed Aug 24 06:19:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Aug 2022 06:19:30 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <9qZ0-uMZWC06EkfnUPXXIF9ejxxw0RbCW1ZvTq0PxMU=.11e0a143-aa8a-47cb-9592-96510f1c8bc7@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
 <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
 <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>
 <MWh3QsYVk4f3NTTJ851ScGPNHWx7LqQ1pkDyDqnHBho=.a87df293-ce45-4244-bfda-b930d82af48e@github.com>
 <9qZ0-uMZWC06EkfnUPXXIF9ejxxw0RbCW1ZvTq0PxMU=.11e0a143-aa8a-47cb-9592-96510f1c8bc7@github.com>
Message-ID: <NPcwPZOXpTAvhGzvNMgQPqVsqkOGbmEuFdM9VmF2b5k=.26857fc2-9442-4a53-984b-0a685f78d074@github.com>

On Tue, 23 Aug 2022 18:57:07 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Suppose we have a scenario where `in` is replaced asynchronously in one of implementations and the implementation is passed into constructor of `DataInputStream`. In this case the patched code is less NPE-vulnerable, isn't it?

I can't imagine a subclass of DataInputStream setting 'in' to null. If it handles async close then it's possible that it replaces it with an input stream where read throws IOException unconditionally. This is why the original patch was problematic for the methods that call in.read in a loop. The updated patch is probably okay, I'm just pointing out that we are forced to think of subclasses when touching this code.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From dfuchs at openjdk.org  Wed Aug 24 10:18:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 Aug 2022 10:18:37 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream
In-Reply-To: <NPcwPZOXpTAvhGzvNMgQPqVsqkOGbmEuFdM9VmF2b5k=.26857fc2-9442-4a53-984b-0a685f78d074@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <zXx41BkZSGuQuaCrej0Aa2DZgykMtk3YGMTFhE2xGLE=.24f9727e-34d4-4b25-860a-0427176dbb71@github.com>
 <-xr8LU02m6LoxzXEVJA8zH5fZs8UtIzV-6DL-bxIDxM=.54dff02d-64f9-4e42-abbb-4472e98d23b3@github.com>
 <ThXfa79YjbNdh1EF8pVO3rcx2FsmGGQ2TydkHyY9u3I=.a68d61d6-d890-402d-9589-956e6d898853@github.com>
 <-7LSfTtYXhBUeB7jlFsvgu4uvF2-6jZQdUIEGb7KRTA=.90d5e5fd-fa60-440e-a18b-5894f07e26c6@github.com>
 <MWh3QsYVk4f3NTTJ851ScGPNHWx7LqQ1pkDyDqnHBho=.a87df293-ce45-4244-bfda-b930d82af48e@github.com>
 <9qZ0-uMZWC06EkfnUPXXIF9ejxxw0RbCW1ZvTq0PxMU=.11e0a143-aa8a-47cb-9592-96510f1c8bc7@github.com>
 <NPcwPZOXpTAvhGzvNMgQPqVsqkOGbmEuFdM9VmF2b5k=.26857fc2-9442-4a53-984b-0a685f78d074@github.com>
Message-ID: <vXR-TKD3FsMjc7usWWmXzmUntIHpU1hZSMKbpmb-i-A=.d88ee49b-bd18-487b-9ae0-487bc537d1ba@github.com>

On Wed, 24 Aug 2022 06:17:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I can't imagine a subclass of DataInputStream setting 'in' to null. If it handles async close then it's possible that it replaces it with an input stream where read throws IOException unconditionally. This is why the original patch was problematic for the methods that call in.read in a loop. The updated patch is probably okay, I'm just pointing out that we are forced to think of subclasses when touching this code.

Thanks Alan - that makes sense to me.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From john.hendrikx at gmail.com  Wed Aug 24 12:12:20 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 24 Aug 2022 14:12:20 +0200
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
Message-ID: <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>

Would it be an option to not make the receiver responsible for the 
decision whether to make a copy or not?? Instead put this burden (using 
default methods) on the various collections?

If List/Set/Map had a method like this:

 ???? List<T> immutableCopy();? // returns a (shallow) immutable copy if 
list is mutable (basically always copies, unless proven otherwise)

Paired with methods on Collections to prevent collections from being 
modified:

 ???? Collections.immutableList(List<T>)

This wrapper is similar to `unmodifiableList` except it implements 
`immutableCopy` as `return this`.

Then for the various scenario's, where `x` is an untrusted source of 
List with unknown status:

 ???? // Create a defensive copy; result is a private list that cannot 
be modified:

 ???? List<T> y = x.immutableCopy();

 ???? // Create a defensive copy for sharing, promising it won't ever 
change:

 ???? List<T> y = Collections.immutableList(x.immutableCopy());

 ???? // Create a defensive copy for mutating:

 ???? List<T> y = new ArrayList<>(x);? // same as always

 ???? // Create a mutable copy, modify it, then expose as immutable:

 ???? List<T> y = new ArrayList<>(x);? // same as always

 ???? y.add( <some element> );

 ???? List<T> z = Collections.immutableList(y);

 ???? y = null;? // we promise `z` won't change again by clearing the 
only path to mutating it!

The advantage would be that this information isn't part of the type 
system where it can easily get lost. The actual implementation knows 
best whether a copy must be made or not.

Of course, the immutableList wrapper can be used incorrectly and the 
promise here can be broken by keeping a reference to the original 
(mutable) list, but I think that's an acceptable trade-off.

--John

PS. Chosen names are just for illustration; there is some discussion as 
what "unmodifiable" vs "immutable" means in the context of collections 
that may contain elements that are mutable. In this post, immutable 
refers to shallow immutability .

On 24/08/2022 03:24, Ethan McCue wrote:
> Ah, I'm an idiot.
>
> There is still a proposal here somewhere...maybe. right now non jdk 
> lists can't participate in the special casing?
>
> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>     List.copyOf already does what you want.
>
>     https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>     https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>
>     Paul.
>
>     > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>     >
>     > Hi all,
>     >
>     > I am running into an issue with the collections framework where
>     I have to choose between good semantics for users and performance.
>     >
>     > Specifically I am taking a java.util.List from my users and I
>     need to choose to either
>     > * Not defensively copy and expose a potential footgun when I
>     pass that List to another thread
>     > * Defensively copy and make my users pay an unnecessary runtime
>     cost.
>     >
>     > What I would really want, in a nutshell, is for List.copyOf to
>     be a no-op when used on lists made with List.of().
>     >
>     > Below the line is a pitch I wrote up on reddit 7 months ago for
>     a mechanism I think could accomplish that. My goal is to share the
>     idea a bit more widely and to this specific audience to get feedback.
>     >
>     >
>     https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>     <https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3>
>
>     >
>     > Important also for context is Ron Pressler's comment above.
>     > --------------
>     >
>     > What if the collections api added more marker interfaces like
>     RandomAccess?
>     >
>     > It's already a common thing for codebases to make explicit null
>     checks at error boundaries because the type system can't encode
>     null | List<String>.
>     >
>     > This feels like a similar problem.
>     > If you have a List<T> in the type system then you don't know for
>     sure you can call any methods on it until you check that its not
>     null. In the same way, there is a set of methods that you don't
>     know at the type/interface level if you are allowed to call.
>     >
>     > If the List is actually a __
>     > Then you can definitely call
>     > And you know other reference holders might call
>     > And you can confirm its this case by
>     > null
>     > no methods
>     > no methods
>     > list == null
>     > List.of(...)
>     > get, size
>     > get, size
>     > ???
>     > Collections.unmodifiableList(...)
>     > get, size
>     > get, size, add, set
>     > ???
>     > Arrays.asList(...)
>     > get, size, set
>     > get, size, set
>     > ???
>     > new ArrayList<>()
>     > get, size, add, set
>     > get, size, add, set
>     > ???
>     > While yes, there is no feasible way to encode these things in
>     the type system. Its not impossible to encode it at runtime though.
>     > interface FullyImmutable {
>     > // So you know the existence of this implies the absence
>     > // of the others
>     > default Void cantIntersect() { return null; }
>     > }
>     >
>     > interace MutationCapability {
>     > default String cantIntersect() { return ""; }
>     > }
>     >
>     > interface Addable extends MutationCapability {}
>     > interface Settable extends MutationCapability {}
>     >
>     > If the List is actually a __
>     > Then you can definitely call
>     > And you know other reference holders might call
>     > And you can confirm its this case by
>     > null
>     > no methods
>     > no methods
>     > list == null
>     > List.of(...)
>     > get, size
>     > get, size
>     > instanceof FullyImmutable
>     > Collections.unmodifiableList(...)
>     > get, size
>     > get, size, add, set
>     > !(instanceof Addable) && !(instanceof Settable)
>     > Arrays.asList(...)
>     > get, size, set
>     > get, size, set
>     > instanceof Settable
>     > new ArrayList<>()
>     > get, size, add, set
>     > get, size, add, set
>     > instanceof Settable && instanceof Addable
>     > In the same way a RandomAccess check let's implementations
>     decide whether they want to try an alternative algorithm or crash,
>     some marker "capability" interfaces would let users of a
>     collection decide if they want to clone what they are given before
>     working on it.
>     >
>     >
>     > --------------
>     >
>     > So the applicability of this would be that the list returned by
>     List.of could implement FullyImmutable, signifying that there is
>     no caller which might have a mutable handle on the collection.
>     Then List.of could check for this interface and skip a copy.
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/29ad90c7/attachment-0001.htm>

From ethan at mccue.dev  Wed Aug 24 13:38:26 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 24 Aug 2022 09:38:26 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
Message-ID: <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>

A use case that doesn't cover is adding to a collection.

Say as part of a method's contract you state that you take ownership of a
List. You aren't going to copy even if the list is mutable.

Later on, you may want to add to the list. Add is supported on ArrayList so
you don't need to copy and replace your reference, but you would if the
list you were given was made with List.of or Arrays.asList

On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com> wrote:

> Would it be an option to not make the receiver responsible for the
> decision whether to make a copy or not?  Instead put this burden (using
> default methods) on the various collections?
>
> If List/Set/Map had a method like this:
>
>      List<T> immutableCopy();  // returns a (shallow) immutable copy if
> list is mutable (basically always copies, unless proven otherwise)
>
> Paired with methods on Collections to prevent collections from being
> modified:
>
>      Collections.immutableList(List<T>)
>
> This wrapper is similar to `unmodifiableList` except it implements
> `immutableCopy` as `return this`.
>
> Then for the various scenario's, where `x` is an untrusted source of List
> with unknown status:
>
>      // Create a defensive copy; result is a private list that cannot be
> modified:
>
>      List<T> y = x.immutableCopy();
>
>      // Create a defensive copy for sharing, promising it won't ever
> change:
>
>      List<T> y = Collections.immutableList(x.immutableCopy());
>
>      // Create a defensive copy for mutating:
>
>      List<T> y = new ArrayList<>(x);  // same as always
>
>      // Create a mutable copy, modify it, then expose as immutable:
>
>      List<T> y = new ArrayList<>(x);  // same as always
>
>      y.add( <some element> );
>
>      List<T> z = Collections.immutableList(y);
>
>      y = null;  // we promise `z` won't change again by clearing the only
> path to mutating it!
>
> The advantage would be that this information isn't part of the type system
> where it can easily get lost. The actual implementation knows best whether
> a copy must be made or not.
>
> Of course, the immutableList wrapper can be used incorrectly and the
> promise here can be broken by keeping a reference to the original (mutable)
> list, but I think that's an acceptable trade-off.
>
> --John
>
> PS. Chosen names are just for illustration; there is some discussion as
> what "unmodifiable" vs "immutable" means in the context of collections that
> may contain elements that are mutable. In this post, immutable refers to
> shallow immutability .
> On 24/08/2022 03:24, Ethan McCue wrote:
>
> Ah, I'm an idiot.
>
> There is still a proposal here somewhere...maybe. right now non jdk lists
> can't participate in the special casing?
>
> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> List.copyOf already does what you want.
>>
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>
>> Paul.
>>
>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>> >
>> > Hi all,
>> >
>> > I am running into an issue with the collections framework where I have
>> to choose between good semantics for users and performance.
>> >
>> > Specifically I am taking a java.util.List from my users and I need to
>> choose to either
>> > * Not defensively copy and expose a potential footgun when I pass that
>> List to another thread
>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>> >
>> > What I would really want, in a nutshell, is for List.copyOf to be a
>> no-op when used on lists made with List.of().
>> >
>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>> mechanism I think could accomplish that. My goal is to share the idea a bit
>> more widely and to this specific audience to get feedback.
>> >
>> >
>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>> >
>> > Important also for context is Ron Pressler's comment above.
>> > --------------
>> >
>> > What if the collections api added more marker interfaces like
>> RandomAccess?
>> >
>> > It's already a common thing for codebases to make explicit null checks
>> at error boundaries because the type system can't encode null |
>> List<String>.
>> >
>> > This feels like a similar problem.
>> > If you have a List<T> in the type system then you don't know for sure
>> you can call any methods on it until you check that its not null. In the
>> same way, there is a set of methods that you don't know at the
>> type/interface level if you are allowed to call.
>> >
>> > If the List is actually a __
>> > Then you can definitely call
>> > And you know other reference holders might call
>> > And you can confirm its this case by
>> > null
>> > no methods
>> > no methods
>> > list == null
>> > List.of(...)
>> > get, size
>> > get, size
>> > ???
>> > Collections.unmodifiableList(...)
>> > get, size
>> > get, size, add, set
>> > ???
>> > Arrays.asList(...)
>> > get, size, set
>> > get, size, set
>> > ???
>> > new ArrayList<>()
>> > get, size, add, set
>> > get, size, add, set
>> > ???
>> > While yes, there is no feasible way to encode these things in the type
>> system. Its not impossible to encode it at runtime though.
>> > interface FullyImmutable {
>> > // So you know the existence of this implies the absence
>> > // of the others
>> > default Void cantIntersect() { return null; }
>> > }
>> >
>> > interace MutationCapability {
>> > default String cantIntersect() { return ""; }
>> > }
>> >
>> > interface Addable extends MutationCapability {}
>> > interface Settable extends MutationCapability {}
>> >
>> > If the List is actually a __
>> > Then you can definitely call
>> > And you know other reference holders might call
>> > And you can confirm its this case by
>> > null
>> > no methods
>> > no methods
>> > list == null
>> > List.of(...)
>> > get, size
>> > get, size
>> > instanceof FullyImmutable
>> > Collections.unmodifiableList(...)
>> > get, size
>> > get, size, add, set
>> > !(instanceof Addable) && !(instanceof Settable)
>> > Arrays.asList(...)
>> > get, size, set
>> > get, size, set
>> > instanceof Settable
>> > new ArrayList<>()
>> > get, size, add, set
>> > get, size, add, set
>> > instanceof Settable && instanceof Addable
>> > In the same way a RandomAccess check let's implementations decide
>> whether they want to try an alternative algorithm or crash, some marker
>> "capability" interfaces would let users of a collection decide if they want
>> to clone what they are given before working on it.
>> >
>> >
>> > --------------
>> >
>> > So the applicability of this would be that the list returned by List.of
>> could implement FullyImmutable, signifying that there is no caller which
>> might have a mutable handle on the collection. Then List.of could check for
>> this interface and skip a copy.
>> >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/7fdb33b5/attachment.htm>

From forax at univ-mlv.fr  Wed Aug 24 14:03:19 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 Aug 2022 16:03:19 +0200 (CEST)
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
Message-ID: <81053966.24568651.1661349799072.JavaMail.zimbra@u-pem.fr>

> From: "Ethan McCue" <ethan at mccue.dev>
> To: "John Hendrikx" <john.hendrikx at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, August 24, 2022 3:38:26 PM
> Subject: Re: Proposal: Collection mutability marker interfaces

> A use case that doesn't cover is adding to a collection.

> Say as part of a method's contract you state that you take ownership of a List.
> You aren't going to copy even if the list is mutable.

> Later on, you may want to add to the list. Add is supported on ArrayList so you
> don't need to copy and replace your reference, but you would if the list you
> were given was made with List.of or Arrays.asList

You can ask if the spliterator considers the collection as immutable or not, 
list.spliterator().hasCharacteristics(Spliterator.IMMUTABLE) 

sadly, List.of()/Map.of() does not report the spliterator characteristics correctly (the spliterator implementations are inherited from AbstracList/AbstractMap). 

so it's perhaps better to call add() inside a try/catch on UnsupportedOperationException. 

R?mi 

> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx < [ mailto:john.hendrikx at gmail.com |
> john.hendrikx at gmail.com ] > wrote:

>> Would it be an option to not make the receiver responsible for the decision
>> whether to make a copy or not? Instead put this burden (using default methods)
>> on the various collections?

>> If List/Set/Map had a method like this:

>> List<T> immutableCopy(); // returns a (shallow) immutable copy if list is
>> mutable (basically always copies, unless proven otherwise)

>> Paired with methods on Collections to prevent collections from being modified:

>> Collections.immutableList(List<T>)

>> This wrapper is similar to `unmodifiableList` except it implements
>> `immutableCopy` as `return this`.

>> Then for the various scenario's, where `x` is an untrusted source of List with
>> unknown status:

>> // Create a defensive copy; result is a private list that cannot be modified:

>> List<T> y = x.immutableCopy();

>> // Create a defensive copy for sharing, promising it won't ever change:

>> List<T> y = Collections.immutableList(x.immutableCopy());

>> // Create a defensive copy for mutating:

>> List<T> y = new ArrayList<>(x); // same as always

>> // Create a mutable copy, modify it, then expose as immutable:

>> List<T> y = new ArrayList<>(x); // same as always

>> y.add( <some element> );

>> List<T> z = Collections.immutableList(y);

>> y = null; // we promise `z` won't change again by clearing the only path to
>> mutating it!

>> The advantage would be that this information isn't part of the type system where
>> it can easily get lost. The actual implementation knows best whether a copy
>> must be made or not.

>> Of course, the immutableList wrapper can be used incorrectly and the promise
>> here can be broken by keeping a reference to the original (mutable) list, but I
>> think that's an acceptable trade-off.

>> --John

>> PS. Chosen names are just for illustration; there is some discussion as what
>> "unmodifiable" vs "immutable" means in the context of collections that may
>> contain elements that are mutable. In this post, immutable refers to shallow
>> immutability .
>> On 24/08/2022 03:24, Ethan McCue wrote:

>>> Ah, I'm an idiot.

>>> There is still a proposal here somewhere...maybe. right now non jdk lists can't
>>> participate in the special casing?

>>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz < [ mailto:paul.sandoz at oracle.com |
>>> paul.sandoz at oracle.com ] > wrote:

>>>> List.copyOf already does what you want.

>>>> [
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>> ]
>>>> [
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>> ]

>>>> Paul.

>>>>> On Aug 23, 2022, at 4:49 PM, Ethan McCue < [ mailto:ethan at mccue.dev |
>>>> > ethan at mccue.dev ] > wrote:

>>>> > Hi all,

>>>>> I am running into an issue with the collections framework where I have to choose
>>>> > between good semantics for users and performance.

>>>>> Specifically I am taking a java.util.List from my users and I need to choose to
>>>> > either
>>>>> * Not defensively copy and expose a potential footgun when I pass that List to
>>>> > another thread
>>>> > * Defensively copy and make my users pay an unnecessary runtime cost.

>>>>> What I would really want, in a nutshell, is for List.copyOf to be a no-op when
>>>> > used on lists made with List.of().

>>>>> Below the line is a pitch I wrote up on reddit 7 months ago for a mechanism I
>>>>> think could accomplish that. My goal is to share the idea a bit more widely and
>>>> > to this specific audience to get feedback.

>>>>> [
>>>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>>> |
>>>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>> > ]

>>>> > Important also for context is Ron Pressler's comment above.
>>>> > --------------

>>>> > What if the collections api added more marker interfaces like RandomAccess?

>>>>> It's already a common thing for codebases to make explicit null checks at error
>>>> > boundaries because the type system can't encode null | List<String>.

>>>> > This feels like a similar problem.
>>>>> If you have a List<T> in the type system then you don't know for sure you can
>>>>> call any methods on it until you check that its not null. In the same way,
>>>>> there is a set of methods that you don't know at the type/interface level if
>>>> > you are allowed to call.

>>>> > If the List is actually a __
>>>> > Then you can definitely call
>>>> > And you know other reference holders might call
>>>> > And you can confirm its this case by
>>>> > null
>>>> > no methods
>>>> > no methods
>>>> > list == null
>>>> > List.of(...)
>>>> > get, size
>>>> > get, size
>>>> > ???
>>>> > Collections.unmodifiableList(...)
>>>> > get, size
>>>> > get, size, add, set
>>>> > ???
>>>> > Arrays.asList(...)
>>>> > get, size, set
>>>> > get, size, set
>>>> > ???
>>>> > new ArrayList<>()
>>>> > get, size, add, set
>>>> > get, size, add, set
>>>> > ???
>>>>> While yes, there is no feasible way to encode these things in the type system.
>>>> > Its not impossible to encode it at runtime though.
>>>> > interface FullyImmutable {
>>>> > // So you know the existence of this implies the absence
>>>> > // of the others
>>>> > default Void cantIntersect() { return null; }
>>>> > }

>>>> > interace MutationCapability {
>>>> > default String cantIntersect() { return ""; }
>>>> > }

>>>> > interface Addable extends MutationCapability {}
>>>> > interface Settable extends MutationCapability {}

>>>> > If the List is actually a __
>>>> > Then you can definitely call
>>>> > And you know other reference holders might call
>>>> > And you can confirm its this case by
>>>> > null
>>>> > no methods
>>>> > no methods
>>>> > list == null
>>>> > List.of(...)
>>>> > get, size
>>>> > get, size
>>>> > instanceof FullyImmutable
>>>> > Collections.unmodifiableList(...)
>>>> > get, size
>>>> > get, size, add, set
>>>> > !(instanceof Addable) && !(instanceof Settable)
>>>> > Arrays.asList(...)
>>>> > get, size, set
>>>> > get, size, set
>>>> > instanceof Settable
>>>> > new ArrayList<>()
>>>> > get, size, add, set
>>>> > get, size, add, set
>>>> > instanceof Settable && instanceof Addable
>>>>> In the same way a RandomAccess check let's implementations decide whether they
>>>>> want to try an alternative algorithm or crash, some marker "capability"
>>>>> interfaces would let users of a collection decide if they want to clone what
>>>> > they are given before working on it.


>>>> > --------------

>>>>> So the applicability of this would be that the list returned by List.of could
>>>>> implement FullyImmutable, signifying that there is no caller which might have a
>>>>> mutable handle on the collection. Then List.of could check for this interface
>>>> > and skip a copy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/f0acba11/attachment-0001.htm>

From roger.riggs at oracle.com  Wed Aug 24 14:26:45 2022
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 24 Aug 2022 10:26:45 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
Message-ID: <dce4a6b9-3d76-7619-e889-8ca06e734a5c@oracle.com>

Hi,

Safety-wise, taking transferring ownership is fraught, the new owner 
can't be certain that the original owner hasn't kept a reference to it 
or to its implementation and might be mucking around with it behind the 
new owners back.

Its cleaner to design the APIs to be defensive, either the API should 
handle the List creation itself (and only expose immutable Lists) or 
make defensive copies before using or saving it.

$0.02, Roger


On 8/24/22 9:38 AM, Ethan McCue wrote:
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state that you take ownership 
> of a List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on 
> ArrayList so you don't need to copy and replace your reference, but 
> you would if the list you were given was made with List.of or 
> Arrays.asList
>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com> 
> wrote:
>
>     Would it be an option to not make the receiver responsible for the
>     decision whether to make a copy or not?? Instead put this burden
>     (using default methods) on the various collections?
>
>     If List/Set/Map had a method like this:
>
>     ???? List<T> immutableCopy();? // returns a (shallow) immutable
>     copy if list is mutable (basically always copies, unless proven
>     otherwise)
>
>     Paired with methods on Collections to prevent collections from
>     being modified:
>
>     ???? Collections.immutableList(List<T>)
>
>     This wrapper is similar to `unmodifiableList` except it implements
>     `immutableCopy` as `return this`.
>
>     Then for the various scenario's, where `x` is an untrusted source
>     of List with unknown status:
>
>     ???? // Create a defensive copy; result is a private list that
>     cannot be modified:
>
>     ???? List<T> y = x.immutableCopy();
>
>     ???? // Create a defensive copy for sharing, promising it won't
>     ever change:
>
>     ???? List<T> y = Collections.immutableList(x.immutableCopy());
>
>     ???? // Create a defensive copy for mutating:
>
>     ???? List<T> y = new ArrayList<>(x);? // same as always
>
>     ???? // Create a mutable copy, modify it, then expose as immutable:
>
>     ???? List<T> y = new ArrayList<>(x);? // same as always
>
>     ???? y.add( <some element> );
>
>     ???? List<T> z = Collections.immutableList(y);
>
>     ???? y = null;? // we promise `z` won't change again by clearing
>     the only path to mutating it!
>
>     The advantage would be that this information isn't part of the
>     type system where it can easily get lost. The actual
>     implementation knows best whether a copy must be made or not.
>
>     Of course, the immutableList wrapper can be used incorrectly and
>     the promise here can be broken by keeping a reference to the
>     original (mutable) list, but I think that's an acceptable trade-off.
>
>     --John
>
>     PS. Chosen names are just for illustration; there is some
>     discussion as what "unmodifiable" vs "immutable" means in the
>     context of collections that may contain elements that are mutable.
>     In this post, immutable refers to shallow immutability .
>
>     On 24/08/2022 03:24, Ethan McCue wrote:
>>     Ah, I'm an idiot.
>>
>>     There is still a proposal here somewhere...maybe. right now non
>>     jdk lists can't participate in the special casing?
>>
>>     On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz
>>     <paul.sandoz at oracle.com> wrote:
>>
>>         List.copyOf already does what you want.
>>
>>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>
>>         Paul.
>>
>>         > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev>
>>         wrote:
>>         >
>>         > Hi all,
>>         >
>>         > I am running into an issue with the collections framework
>>         where I have to choose between good semantics for users and
>>         performance.
>>         >
>>         > Specifically I am taking a java.util.List from my users and
>>         I need to choose to either
>>         > * Not defensively copy and expose a potential footgun when
>>         I pass that List to another thread
>>         > * Defensively copy and make my users pay an unnecessary
>>         runtime cost.
>>         >
>>         > What I would really want, in a nutshell, is for List.copyOf
>>         to be a no-op when used on lists made with List.of().
>>         >
>>         > Below the line is a pitch I wrote up on reddit 7 months ago
>>         for a mechanism I think could accomplish that. My goal is to
>>         share the idea a bit more widely and to this specific
>>         audience to get feedback.
>>         >
>>         >
>>         https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>         <https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3>
>>
>>         >
>>         > Important also for context is Ron Pressler's comment above.
>>         > --------------
>>         >
>>         > What if the collections api added more marker interfaces
>>         like RandomAccess?
>>         >
>>         > It's already a common thing for codebases to make explicit
>>         null checks at error boundaries because the type system can't
>>         encode null | List<String>.
>>         >
>>         > This feels like a similar problem.
>>         > If you have a List<T> in the type system then you don't
>>         know for sure you can call any methods on it until you check
>>         that its not null. In the same way, there is a set of methods
>>         that you don't know at the type/interface level if you are
>>         allowed to call.
>>         >
>>         > If the List is actually a __
>>         > Then you can definitely call
>>         > And you know other reference holders might call
>>         > And you can confirm its this case by
>>         > null
>>         > no methods
>>         > no methods
>>         > list == null
>>         > List.of(...)
>>         > get, size
>>         > get, size
>>         > ???
>>         > Collections.unmodifiableList(...)
>>         > get, size
>>         > get, size, add, set
>>         > ???
>>         > Arrays.asList(...)
>>         > get, size, set
>>         > get, size, set
>>         > ???
>>         > new ArrayList<>()
>>         > get, size, add, set
>>         > get, size, add, set
>>         > ???
>>         > While yes, there is no feasible way to encode these things
>>         in the type system. Its not impossible to encode it at
>>         runtime though.
>>         > interface FullyImmutable {
>>         > // So you know the existence of this implies the absence
>>         > // of the others
>>         > default Void cantIntersect() { return null; }
>>         > }
>>         >
>>         > interace MutationCapability {
>>         > default String cantIntersect() { return ""; }
>>         > }
>>         >
>>         > interface Addable extends MutationCapability {}
>>         > interface Settable extends MutationCapability {}
>>         >
>>         > If the List is actually a __
>>         > Then you can definitely call
>>         > And you know other reference holders might call
>>         > And you can confirm its this case by
>>         > null
>>         > no methods
>>         > no methods
>>         > list == null
>>         > List.of(...)
>>         > get, size
>>         > get, size
>>         > instanceof FullyImmutable
>>         > Collections.unmodifiableList(...)
>>         > get, size
>>         > get, size, add, set
>>         > !(instanceof Addable) && !(instanceof Settable)
>>         > Arrays.asList(...)
>>         > get, size, set
>>         > get, size, set
>>         > instanceof Settable
>>         > new ArrayList<>()
>>         > get, size, add, set
>>         > get, size, add, set
>>         > instanceof Settable && instanceof Addable
>>         > In the same way a RandomAccess check let's implementations
>>         decide whether they want to try an alternative algorithm or
>>         crash, some marker "capability" interfaces would let users of
>>         a collection decide if they want to clone what they are given
>>         before working on it.
>>         >
>>         >
>>         > --------------
>>         >
>>         > So the applicability of this would be that the list
>>         returned by List.of could implement FullyImmutable,
>>         signifying that there is no caller which might have a mutable
>>         handle on the collection. Then List.of could check for this
>>         interface and skip a copy.
>>         >
>>         >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/25ea8539/attachment-0001.htm>

From ethan at mccue.dev  Wed Aug 24 14:27:01 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 24 Aug 2022 10:27:01 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <81053966.24568651.1661349799072.JavaMail.zimbra@u-pem.fr>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <81053966.24568651.1661349799072.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+NR86gnNvv5UkM_ViAuK1WK6cRJtk0ur=oqutCpad+LOdgs3A@mail.gmail.com>

> so it's perhaps better to call add() inside a try/catch on
UnsupportedOperationException.

As much as sin is wrong, sketching out what that might look like... forgive
the toyness of the example

final class Ex {
    private Ex() {}

    /*
     * Adds the odd numbers from 1 to 10 to the List then makes all the
odds even.
     *
     * Takes ownership of the list, avoids making copies if it doesn't need
to
     */
    static List<Integer> addOdds(List<Integer> l) {
        for (int i = 1; i <= 10; i++) {
            l.add(i);
        }

        for (int i = 0; i < l.size(); i++) {
            if (l.get(i) % 2 == 1) {
                l.set(i, l.get(i) + 1);
            }
        }
    }
}


VS



final class Ex {
    private Ex() {}

    /*
     * Adds the odd numbers from 1 to 10 to the List then makes all the
odds even.
     *
     * Takes ownership of the list, avoids making copies if it doesn't need
to
     */
    static List<Integer> addOdds(List<Integer> l) {
        for (int i = 1; i <= 10; i++) {
            try {
                l.add(i);
            } catch (UnsupportedOperationException e) {
                l = new ArrayList<>(l);
            }
        }

        for (int i = 0; i < l.size(); i++) {
            if (l.get(i) % 2 == 1) {
                try {
                    l.set(i, l.get(i) + 1);
                } catch (UnsupportedOperationException e) {
                    l = new ArrayList<>(l);
                }
            }
        }
    }
}

VS

final class Ex {
    private Ex() {}

    /*
     * Adds the odd numbers from 1 to 10 to the List then makes all the
odds even.
     *
     * Takes ownership of the list, avoids making copies if it doesn't need
to
     */
    static List<Integer> addOdds(List<Integer> l) {
        if (!(l instanceof Settable && l instanceof Addable)) {
            l = new ArrayList<>(l);
        }
        for (int i = 1; i <= 10; i++) {
            l.add(i);
        }

        for (int i = 0; i < l.size(); i++) {
            if (l.get(i) % 2 == 1) {
                l.set(i, l.get(i) + 1);
            }
        }
    }
}



On Wed, Aug 24, 2022 at 10:03 AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Ethan McCue" <ethan at mccue.dev>
> *To: *"John Hendrikx" <john.hendrikx at gmail.com>
> *Cc: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Wednesday, August 24, 2022 3:38:26 PM
> *Subject: *Re: Proposal: Collection mutability marker interfaces
>
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state that you take ownership of a
> List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on ArrayList
> so you don't need to copy and replace your reference, but you would if the
> list you were given was made with List.of or Arrays.asList
>
>
> You can ask if the spliterator considers the collection as immutable or
> not,
>   list.spliterator().hasCharacteristics(Spliterator.IMMUTABLE)
>
> sadly, List.of()/Map.of() does not report the spliterator characteristics
> correctly (the spliterator implementations are inherited from
> AbstracList/AbstractMap).
>
> so it's perhaps better to call add() inside a try/catch on
> UnsupportedOperationException.
>
> R?mi
>
>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> Would it be an option to not make the receiver responsible for the
>> decision whether to make a copy or not?  Instead put this burden (using
>> default methods) on the various collections?
>>
>> If List/Set/Map had a method like this:
>>
>>      List<T> immutableCopy();  // returns a (shallow) immutable copy if
>> list is mutable (basically always copies, unless proven otherwise)
>>
>> Paired with methods on Collections to prevent collections from being
>> modified:
>>
>>      Collections.immutableList(List<T>)
>>
>> This wrapper is similar to `unmodifiableList` except it implements
>> `immutableCopy` as `return this`.
>>
>> Then for the various scenario's, where `x` is an untrusted source of List
>> with unknown status:
>>
>>      // Create a defensive copy; result is a private list that cannot be
>> modified:
>>
>>      List<T> y = x.immutableCopy();
>>
>>      // Create a defensive copy for sharing, promising it won't ever
>> change:
>>
>>      List<T> y = Collections.immutableList(x.immutableCopy());
>>
>>      // Create a defensive copy for mutating:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      // Create a mutable copy, modify it, then expose as immutable:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      y.add( <some element> );
>>
>>      List<T> z = Collections.immutableList(y);
>>
>>      y = null;  // we promise `z` won't change again by clearing the only
>> path to mutating it!
>>
>> The advantage would be that this information isn't part of the type
>> system where it can easily get lost. The actual implementation knows best
>> whether a copy must be made or not.
>>
>> Of course, the immutableList wrapper can be used incorrectly and the
>> promise here can be broken by keeping a reference to the original (mutable)
>> list, but I think that's an acceptable trade-off.
>>
>> --John
>>
>> PS. Chosen names are just for illustration; there is some discussion as
>> what "unmodifiable" vs "immutable" means in the context of collections that
>> may contain elements that are mutable. In this post, immutable refers to
>> shallow immutability .
>> On 24/08/2022 03:24, Ethan McCue wrote:
>>
>> Ah, I'm an idiot.
>>
>> There is still a proposal here somewhere...maybe. right now non jdk lists
>> can't participate in the special casing?
>>
>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> List.copyOf already does what you want.
>>>
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>
>>> Paul.
>>>
>>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I am running into an issue with the collections framework where I have
>>> to choose between good semantics for users and performance.
>>> >
>>> > Specifically I am taking a java.util.List from my users and I need to
>>> choose to either
>>> > * Not defensively copy and expose a potential footgun when I pass that
>>> List to another thread
>>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>>> >
>>> > What I would really want, in a nutshell, is for List.copyOf to be a
>>> no-op when used on lists made with List.of().
>>> >
>>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>>> mechanism I think could accomplish that. My goal is to share the idea a bit
>>> more widely and to this specific audience to get feedback.
>>> >
>>> >
>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>> >
>>> > Important also for context is Ron Pressler's comment above.
>>> > --------------
>>> >
>>> > What if the collections api added more marker interfaces like
>>> RandomAccess?
>>> >
>>> > It's already a common thing for codebases to make explicit null checks
>>> at error boundaries because the type system can't encode null |
>>> List<String>.
>>> >
>>> > This feels like a similar problem.
>>> > If you have a List<T> in the type system then you don't know for sure
>>> you can call any methods on it until you check that its not null. In the
>>> same way, there is a set of methods that you don't know at the
>>> type/interface level if you are allowed to call.
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > ???
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > ???
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > ???
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > ???
>>> > While yes, there is no feasible way to encode these things in the type
>>> system. Its not impossible to encode it at runtime though.
>>> > interface FullyImmutable {
>>> > // So you know the existence of this implies the absence
>>> > // of the others
>>> > default Void cantIntersect() { return null; }
>>> > }
>>> >
>>> > interace MutationCapability {
>>> > default String cantIntersect() { return ""; }
>>> > }
>>> >
>>> > interface Addable extends MutationCapability {}
>>> > interface Settable extends MutationCapability {}
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > instanceof FullyImmutable
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > !(instanceof Addable) && !(instanceof Settable)
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > instanceof Settable
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > instanceof Settable && instanceof Addable
>>> > In the same way a RandomAccess check let's implementations decide
>>> whether they want to try an alternative algorithm or crash, some marker
>>> "capability" interfaces would let users of a collection decide if they want
>>> to clone what they are given before working on it.
>>> >
>>> >
>>> > --------------
>>> >
>>> > So the applicability of this would be that the list returned by
>>> List.of could implement FullyImmutable, signifying that there is no caller
>>> which might have a mutable handle on the collection. Then List.of could
>>> check for this interface and skip a copy.
>>> >
>>> >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/e0849304/attachment-0001.htm>

From ethan at mccue.dev  Wed Aug 24 14:31:54 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 24 Aug 2022 10:31:54 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <dce4a6b9-3d76-7619-e889-8ca06e734a5c@oracle.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <dce4a6b9-3d76-7619-e889-8ca06e734a5c@oracle.com>
Message-ID: <CA+NR86iXmycvWq2cAT68Eq59=DQtgaOotW=HkEGxdche1gRLdQ@mail.gmail.com>

> Safety-wise, taking transferring ownership is fraught

True, or at the very least a true-ism we generally accept.

But that's still a deliberate choice to make that makes a performance
tradeoff. The risk of misuse is proportional always to the exposure of and
audience of the api.

On Wed, Aug 24, 2022 at 10:28 AM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> Safety-wise, taking transferring ownership is fraught, the new owner can't
> be certain that the original owner hasn't kept a reference to it or to its
> implementation and might be mucking around with it behind the new owners
> back.
>
> Its cleaner to design the APIs to be defensive, either the API should
> handle the List creation itself (and only expose immutable Lists) or make
> defensive copies before using or saving it.
>
> $0.02, Roger
>
>
> On 8/24/22 9:38 AM, Ethan McCue wrote:
>
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state that you take ownership of a
> List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on ArrayList
> so you don't need to copy and replace your reference, but you would if the
> list you were given was made with List.of or Arrays.asList
>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> Would it be an option to not make the receiver responsible for the
>> decision whether to make a copy or not?  Instead put this burden (using
>> default methods) on the various collections?
>>
>> If List/Set/Map had a method like this:
>>
>>      List<T> immutableCopy();  // returns a (shallow) immutable copy if
>> list is mutable (basically always copies, unless proven otherwise)
>>
>> Paired with methods on Collections to prevent collections from being
>> modified:
>>
>>      Collections.immutableList(List<T>)
>>
>> This wrapper is similar to `unmodifiableList` except it implements
>> `immutableCopy` as `return this`.
>>
>> Then for the various scenario's, where `x` is an untrusted source of List
>> with unknown status:
>>
>>      // Create a defensive copy; result is a private list that cannot be
>> modified:
>>
>>      List<T> y = x.immutableCopy();
>>
>>      // Create a defensive copy for sharing, promising it won't ever
>> change:
>>
>>      List<T> y = Collections.immutableList(x.immutableCopy());
>>
>>      // Create a defensive copy for mutating:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      // Create a mutable copy, modify it, then expose as immutable:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      y.add( <some element> );
>>
>>      List<T> z = Collections.immutableList(y);
>>
>>      y = null;  // we promise `z` won't change again by clearing the only
>> path to mutating it!
>>
>> The advantage would be that this information isn't part of the type
>> system where it can easily get lost. The actual implementation knows best
>> whether a copy must be made or not.
>>
>> Of course, the immutableList wrapper can be used incorrectly and the
>> promise here can be broken by keeping a reference to the original (mutable)
>> list, but I think that's an acceptable trade-off.
>>
>> --John
>>
>> PS. Chosen names are just for illustration; there is some discussion as
>> what "unmodifiable" vs "immutable" means in the context of collections that
>> may contain elements that are mutable. In this post, immutable refers to
>> shallow immutability .
>> On 24/08/2022 03:24, Ethan McCue wrote:
>>
>> Ah, I'm an idiot.
>>
>> There is still a proposal here somewhere...maybe. right now non jdk lists
>> can't participate in the special casing?
>>
>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> List.copyOf already does what you want.
>>>
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>
>>> Paul.
>>>
>>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I am running into an issue with the collections framework where I have
>>> to choose between good semantics for users and performance.
>>> >
>>> > Specifically I am taking a java.util.List from my users and I need to
>>> choose to either
>>> > * Not defensively copy and expose a potential footgun when I pass that
>>> List to another thread
>>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>>> >
>>> > What I would really want, in a nutshell, is for List.copyOf to be a
>>> no-op when used on lists made with List.of().
>>> >
>>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>>> mechanism I think could accomplish that. My goal is to share the idea a bit
>>> more widely and to this specific audience to get feedback.
>>> >
>>> >
>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>> >
>>> > Important also for context is Ron Pressler's comment above.
>>> > --------------
>>> >
>>> > What if the collections api added more marker interfaces like
>>> RandomAccess?
>>> >
>>> > It's already a common thing for codebases to make explicit null checks
>>> at error boundaries because the type system can't encode null |
>>> List<String>.
>>> >
>>> > This feels like a similar problem.
>>> > If you have a List<T> in the type system then you don't know for sure
>>> you can call any methods on it until you check that its not null. In the
>>> same way, there is a set of methods that you don't know at the
>>> type/interface level if you are allowed to call.
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > ???
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > ???
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > ???
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > ???
>>> > While yes, there is no feasible way to encode these things in the type
>>> system. Its not impossible to encode it at runtime though.
>>> > interface FullyImmutable {
>>> > // So you know the existence of this implies the absence
>>> > // of the others
>>> > default Void cantIntersect() { return null; }
>>> > }
>>> >
>>> > interace MutationCapability {
>>> > default String cantIntersect() { return ""; }
>>> > }
>>> >
>>> > interface Addable extends MutationCapability {}
>>> > interface Settable extends MutationCapability {}
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > instanceof FullyImmutable
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > !(instanceof Addable) && !(instanceof Settable)
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > instanceof Settable
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > instanceof Settable && instanceof Addable
>>> > In the same way a RandomAccess check let's implementations decide
>>> whether they want to try an alternative algorithm or crash, some marker
>>> "capability" interfaces would let users of a collection decide if they want
>>> to clone what they are given before working on it.
>>> >
>>> >
>>> > --------------
>>> >
>>> > So the applicability of this would be that the list returned by
>>> List.of could implement FullyImmutable, signifying that there is no caller
>>> which might have a mutable handle on the collection. Then List.of could
>>> check for this interface and skip a copy.
>>> >
>>> >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/24a077f4/attachment.htm>

From forax at univ-mlv.fr  Wed Aug 24 15:21:47 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 24 Aug 2022 17:21:47 +0200 (CEST)
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86gnNvv5UkM_ViAuK1WK6cRJtk0ur=oqutCpad+LOdgs3A@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <81053966.24568651.1661349799072.JavaMail.zimbra@u-pem.fr>
 <CA+NR86gnNvv5UkM_ViAuK1WK6cRJtk0ur=oqutCpad+LOdgs3A@mail.gmail.com>
Message-ID: <114452601.24603626.1661354507336.JavaMail.zimbra@u-pem.fr>

> From: "Ethan McCue" <ethan at mccue.dev>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Hendrikx" <john.hendrikx at gmail.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Wednesday, August 24, 2022 4:27:01 PM
> Subject: Re: Proposal: Collection mutability marker interfaces

>> so it's perhaps better to call add() inside a try/catch on
> > UnsupportedOperationException.

> As much as sin is wrong, sketching out what that might look like... forgive the
> toyness of the example

> VS

> final class Ex {
> private Ex() {}

> /*
> * Adds the odd numbers from 1 to 10 to the List then makes all the odds even.
> *
> * Takes ownership of the list, avoids making copies if it doesn't need to
> */
> static List<Integer> addOdds(List<Integer> l) {
> for (int i = 1; i <= 10; i++) {
> try {
> l.add(i);
> } catch (UnsupportedOperationException e) {
> l = new ArrayList<>(l);

i -= 1; // restart with an ArrayList 

> }
> }

> for (int i = 0; i < l.size(); i++) {
> if (l.get(i) % 2 == 1) {
> try {
> l.set(i, l.get(i) + 1);
> } catch (UnsupportedOperationException e) {
> l = new ArrayList<>(l);
> }
> }
> }
> }
> }

as Roger said, there is no way in Java to know if the caller has not kept a reference (unlike Rust), 
so having trouble to write this kind of code is more a feature than an issue :) 

This kind of examples scream the Stream API, which has the correct semantics 
IntStream.rangeClosed(1, 10).map(i -> i % 2 == 0? i + 1: i).boxed().toList() 

R?mi 

> On Wed, Aug 24, 2022 at 10:03 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> From: "Ethan McCue" < [ mailto:ethan at mccue.dev | ethan at mccue.dev ] >
>>> To: "John Hendrikx" < [ mailto:john.hendrikx at gmail.com | john.hendrikx at gmail.com
>>> ] >
>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>>> core-libs-dev at openjdk.org ] >
>>> Sent: Wednesday, August 24, 2022 3:38:26 PM
>>> Subject: Re: Proposal: Collection mutability marker interfaces

>>> A use case that doesn't cover is adding to a collection.

>>> Say as part of a method's contract you state that you take ownership of a List.
>>> You aren't going to copy even if the list is mutable.

>>> Later on, you may want to add to the list. Add is supported on ArrayList so you
>>> don't need to copy and replace your reference, but you would if the list you
>>> were given was made with List.of or Arrays.asList

>> You can ask if the spliterator considers the collection as immutable or not,
>> list.spliterator().hasCharacteristics(Spliterator.IMMUTABLE)

>> sadly, List.of()/Map.of() does not report the spliterator characteristics
>> correctly (the spliterator implementations are inherited from
>> AbstracList/AbstractMap).

>> so it's perhaps better to call add() inside a try/catch on
>> UnsupportedOperationException.

>> R?mi

>>> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx < [ mailto:john.hendrikx at gmail.com |
>>> john.hendrikx at gmail.com ] > wrote:

>>>> Would it be an option to not make the receiver responsible for the decision
>>>> whether to make a copy or not? Instead put this burden (using default methods)
>>>> on the various collections?

>>>> If List/Set/Map had a method like this:

>>>> List<T> immutableCopy(); // returns a (shallow) immutable copy if list is
>>>> mutable (basically always copies, unless proven otherwise)

>>>> Paired with methods on Collections to prevent collections from being modified:

>>>> Collections.immutableList(List<T>)

>>>> This wrapper is similar to `unmodifiableList` except it implements
>>>> `immutableCopy` as `return this`.

>>>> Then for the various scenario's, where `x` is an untrusted source of List with
>>>> unknown status:

>>>> // Create a defensive copy; result is a private list that cannot be modified:

>>>> List<T> y = x.immutableCopy();

>>>> // Create a defensive copy for sharing, promising it won't ever change:

>>>> List<T> y = Collections.immutableList(x.immutableCopy());

>>>> // Create a defensive copy for mutating:

>>>> List<T> y = new ArrayList<>(x); // same as always

>>>> // Create a mutable copy, modify it, then expose as immutable:

>>>> List<T> y = new ArrayList<>(x); // same as always

>>>> y.add( <some element> );

>>>> List<T> z = Collections.immutableList(y);

>>>> y = null; // we promise `z` won't change again by clearing the only path to
>>>> mutating it!

>>>> The advantage would be that this information isn't part of the type system where
>>>> it can easily get lost. The actual implementation knows best whether a copy
>>>> must be made or not.

>>>> Of course, the immutableList wrapper can be used incorrectly and the promise
>>>> here can be broken by keeping a reference to the original (mutable) list, but I
>>>> think that's an acceptable trade-off.

>>>> --John

>>>> PS. Chosen names are just for illustration; there is some discussion as what
>>>> "unmodifiable" vs "immutable" means in the context of collections that may
>>>> contain elements that are mutable. In this post, immutable refers to shallow
>>>> immutability .
>>>> On 24/08/2022 03:24, Ethan McCue wrote:

>>>>> Ah, I'm an idiot.

>>>>> There is still a proposal here somewhere...maybe. right now non jdk lists can't
>>>>> participate in the special casing?

>>>>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz < [ mailto:paul.sandoz at oracle.com |
>>>>> paul.sandoz at oracle.com ] > wrote:

>>>>>> List.copyOf already does what you want.

>>>>>> [
>>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>>>> |
>>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>>>> ]
>>>>>> [
>>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>>>> |
>>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>>>> ]

>>>>>> Paul.

>>>>>>> On Aug 23, 2022, at 4:49 PM, Ethan McCue < [ mailto:ethan at mccue.dev |
>>>>>> > ethan at mccue.dev ] > wrote:

>>>>>> > Hi all,

>>>>>>> I am running into an issue with the collections framework where I have to choose
>>>>>> > between good semantics for users and performance.

>>>>>>> Specifically I am taking a java.util.List from my users and I need to choose to
>>>>>> > either
>>>>>>> * Not defensively copy and expose a potential footgun when I pass that List to
>>>>>> > another thread
>>>>>> > * Defensively copy and make my users pay an unnecessary runtime cost.

>>>>>>> What I would really want, in a nutshell, is for List.copyOf to be a no-op when
>>>>>> > used on lists made with List.of().

>>>>>>> Below the line is a pitch I wrote up on reddit 7 months ago for a mechanism I
>>>>>>> think could accomplish that. My goal is to share the idea a bit more widely and
>>>>>> > to this specific audience to get feedback.

>>>>>>> [
>>>>>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>>>>> |
>>>>>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>>>> > ]

>>>>>> > Important also for context is Ron Pressler's comment above.
>>>>>> > --------------

>>>>>> > What if the collections api added more marker interfaces like RandomAccess?

>>>>>>> It's already a common thing for codebases to make explicit null checks at error
>>>>>> > boundaries because the type system can't encode null | List<String>.

>>>>>> > This feels like a similar problem.
>>>>>>> If you have a List<T> in the type system then you don't know for sure you can
>>>>>>> call any methods on it until you check that its not null. In the same way,
>>>>>>> there is a set of methods that you don't know at the type/interface level if
>>>>>> > you are allowed to call.

>>>>>> > If the List is actually a __
>>>>>> > Then you can definitely call
>>>>>> > And you know other reference holders might call
>>>>>> > And you can confirm its this case by
>>>>>> > null
>>>>>> > no methods
>>>>>> > no methods
>>>>>> > list == null
>>>>>> > List.of(...)
>>>>>> > get, size
>>>>>> > get, size
>>>>>> > ???
>>>>>> > Collections.unmodifiableList(...)
>>>>>> > get, size
>>>>>> > get, size, add, set
>>>>>> > ???
>>>>>> > Arrays.asList(...)
>>>>>> > get, size, set
>>>>>> > get, size, set
>>>>>> > ???
>>>>>> > new ArrayList<>()
>>>>>> > get, size, add, set
>>>>>> > get, size, add, set
>>>>>> > ???
>>>>>>> While yes, there is no feasible way to encode these things in the type system.
>>>>>> > Its not impossible to encode it at runtime though.
>>>>>> > interface FullyImmutable {
>>>>>> > // So you know the existence of this implies the absence
>>>>>> > // of the others
>>>>>> > default Void cantIntersect() { return null; }
>>>>>> > }

>>>>>> > interace MutationCapability {
>>>>>> > default String cantIntersect() { return ""; }
>>>>>> > }

>>>>>> > interface Addable extends MutationCapability {}
>>>>>> > interface Settable extends MutationCapability {}

>>>>>> > If the List is actually a __
>>>>>> > Then you can definitely call
>>>>>> > And you know other reference holders might call
>>>>>> > And you can confirm its this case by
>>>>>> > null
>>>>>> > no methods
>>>>>> > no methods
>>>>>> > list == null
>>>>>> > List.of(...)
>>>>>> > get, size
>>>>>> > get, size
>>>>>> > instanceof FullyImmutable
>>>>>> > Collections.unmodifiableList(...)
>>>>>> > get, size
>>>>>> > get, size, add, set
>>>>>> > !(instanceof Addable) && !(instanceof Settable)
>>>>>> > Arrays.asList(...)
>>>>>> > get, size, set
>>>>>> > get, size, set
>>>>>> > instanceof Settable
>>>>>> > new ArrayList<>()
>>>>>> > get, size, add, set
>>>>>> > get, size, add, set
>>>>>> > instanceof Settable && instanceof Addable
>>>>>>> In the same way a RandomAccess check let's implementations decide whether they
>>>>>>> want to try an alternative algorithm or crash, some marker "capability"
>>>>>>> interfaces would let users of a collection decide if they want to clone what
>>>>>> > they are given before working on it.


>>>>>> > --------------

>>>>>>> So the applicability of this would be that the list returned by List.of could
>>>>>>> implement FullyImmutable, signifying that there is no caller which might have a
>>>>>>> mutable handle on the collection. Then List.of could check for this interface
>>>>>> > and skip a copy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220824/f1349613/attachment-0001.htm>

From duke at openjdk.org  Wed Aug 24 15:58:07 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Aug 2022 15:58:07 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
Message-ID: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>

Add support for named groups to java.util.regex.MatchResult

-------------

Commit messages:
 - 8065554: MatchResult should provide values of named-capturing groups

Changes: https://git.openjdk.org/jdk/pull/10000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8065554
  Stats: 554 lines in 4 files changed: 502 ins; 15 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From dfuchs at openjdk.org  Wed Aug 24 16:06:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 Aug 2022 16:06:26 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>

On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> Add support for named groups to java.util.regex.MatchResult

src/java.base/share/classes/java/util/regex/MatchResult.java line 274:

> 272:      *          might be preferable for other reasons.
> 273:      *
> 274:      * @since 20

Should the method declare that it throws `UnsupportedOperationsExceptions`?
Because that is what will happen if `namedGroups` is not overridden/implemented.

Same comment for the other new methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Wed Aug 24 16:16:33 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Aug 2022 16:16:33 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
In-Reply-To: <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>
Message-ID: <_lIF2mJZGKbXMU__Je14qfzE1lzApjzaUuVAJe8Gfm8=.721b09fb-8a68-4039-be57-d56c9a3c1282@github.com>

On Wed, 24 Aug 2022 16:02:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> src/java.base/share/classes/java/util/regex/MatchResult.java line 274:
> 
>> 272:      *          might be preferable for other reasons.
>> 273:      *
>> 274:      * @since 20
> 
> Should the method declare that it throws `UnsupportedOperationsExceptions`?
> Because that is what will happen if `namedGroups` is not overridden/implemented.
> 
> Same comment for the other new methods.

Not sure.
If the convention is to document every single `RuntimeException` that methods invoked by this one could throw, then yes.
In other words, should `RuntimeExcpetion`s thrown deep in an invocation stack be documented in every caller method?

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From dfuchs at openjdk.org  Wed Aug 24 17:36:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 Aug 2022 17:36:21 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
In-Reply-To: <_lIF2mJZGKbXMU__Je14qfzE1lzApjzaUuVAJe8Gfm8=.721b09fb-8a68-4039-be57-d56c9a3c1282@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>
 <_lIF2mJZGKbXMU__Je14qfzE1lzApjzaUuVAJe8Gfm8=.721b09fb-8a68-4039-be57-d56c9a3c1282@github.com>
Message-ID: <nkvwXMJZ2Qux43D6SynWLafm8O3nVqdd9lyO_SGWPYs=.d814925a-5f9f-4c59-ac53-4a1b02379727@github.com>

On Wed, 24 Aug 2022 16:12:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/regex/MatchResult.java line 274:
>> 
>>> 272:      *          might be preferable for other reasons.
>>> 273:      *
>>> 274:      * @since 20
>> 
>> Should the method declare that it throws `UnsupportedOperationsExceptions`?
>> Because that is what will happen if `namedGroups` is not overridden/implemented.
>> 
>> Same comment for the other new methods.
>
> Not sure.
> If the convention is to document every single `RuntimeException` that methods invoked by this one could throw, then yes.
> In other words, should `RuntimeExcpetion`s thrown deep in an invocation stack be documented in every caller method?

In principle, yes. In practice, I see that `namedGroups` doesn't have an `@throws UnsupportedOperationException` but has an `@implSpec` that says that the default implementation throws `UnsupportedOperationException`. This seems strange to me - maybe @stuart-marks or @jddarcy can comment.

What I was hinting at here however is that we might want to extend the `@implSpec` of the new methods to note that these method will throw `UnsuportedOperationException` if `namedGroups` is not implemented (like the `@implSpec` of `namedGroups` does).

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From shade at openjdk.org  Wed Aug 24 18:23:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Aug 2022 18:23:17 GMT
Subject: RFR: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
Message-ID: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>

[JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.

They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.

See the investigation on RISC-V here:
  https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html

We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."

Additional testing:
 - [x] Linux x86_64, `java/util/concurrent` tests

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10002/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292877
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10002.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10002/head:pull/10002

PR: https://git.openjdk.org/jdk/pull/10002

From duke at openjdk.org  Wed Aug 24 18:26:38 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Aug 2022 18:26:38 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
In-Reply-To: <nkvwXMJZ2Qux43D6SynWLafm8O3nVqdd9lyO_SGWPYs=.d814925a-5f9f-4c59-ac53-4a1b02379727@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>
 <_lIF2mJZGKbXMU__Je14qfzE1lzApjzaUuVAJe8Gfm8=.721b09fb-8a68-4039-be57-d56c9a3c1282@github.com>
 <nkvwXMJZ2Qux43D6SynWLafm8O3nVqdd9lyO_SGWPYs=.d814925a-5f9f-4c59-ac53-4a1b02379727@github.com>
Message-ID: <c_Sef77UI5qcRZkDtFKdnubW-zqMlLa2IV7czUZVzEs=.5fa28b8e-8aae-471a-a986-c2018b1d0999@github.com>

On Wed, 24 Aug 2022 17:34:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Not sure.
>> If the convention is to document every single `RuntimeException` that methods invoked by this one could throw, then yes.
>> In other words, should `RuntimeExcpetion`s thrown deep in an invocation stack be documented in every caller method?
>
> In principle, yes. In practice, I see that `namedGroups` doesn't have an `@throws UnsupportedOperationException` but has an `@implSpec` that says that the default implementation throws `UnsupportedOperationException`. This seems strange to me - maybe @stuart-marks or @jddarcy can comment.
> 
> What I was hinting at here however is that we might want to extend the `@implSpec` of the new methods to note that these method will throw `UnsuportedOperationException` if `namedGroups` is not implemented (like the `@implSpec` of `namedGroups` does).

Ah, I see.
So what you mean is not adding another @throws clause but to either improve @implNote or, better, to add @implSpec.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From psandoz at openjdk.org  Wed Aug 24 18:52:31 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Aug 2022 18:52:31 GMT
Subject: RFR: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
In-Reply-To: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
References: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
Message-ID: <NHThktzUiVQiSWFWDdYTH_lw07uHA76Wrfh40iIqT9U=.d8535bd2-e146-443d-9676-f6f365a7f887@github.com>

On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.
> 
> They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.
> 
> See the investigation on RISC-V here:
>   https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html
> 
> We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."
> 
> Additional testing:
>  - [x] Linux x86_64, `java/util/concurrent` tests

An interesting failure!

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10002

From martin at openjdk.org  Wed Aug 24 19:59:26 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 24 Aug 2022 19:59:26 GMT
Subject: RFR: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
In-Reply-To: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
References: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
Message-ID: <aOARz7SAcflmt3k7MhheRJFnVlZ4M8H5ox80gflKP_Q=.40563bd2-5fc4-487b-8e08-9224b9c9dd57@github.com>

On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.
> 
> They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.
> 
> See the investigation on RISC-V here:
>   https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html
> 
> We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."
> 
> Additional testing:
>  - [x] Linux x86_64, `java/util/concurrent` tests

IIRC I worked on 
test/jdk/java/util/concurrent/tck/LongAdderTest.java:testSerialization
test/jdk/java/util/concurrent/tck/DoubleAdderTest.java:testSerialization
I should have added similar tests back then, to 
DoubleAccumulatorTest.java
LongAccumulatorTest.java
and that would allow deletion of Serial.java as a redundant test.
I would have done that now as well, but there's nothing wrong with this fix.

-------------

Marked as reviewed by martin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10002

From jason_mehrens at hotmail.com  Wed Aug 24 20:26:57 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 24 Aug 2022 20:26:57 +0000
Subject: CopyOnWriteArrayList Collection.shuffle
In-Reply-To: <CAMETwp7LCVBLxfo25r7aqQ_X8vXjOOf5t=u5uG5X9EJ0a9O+cA@mail.gmail.com>
References: <CAMETwp7LCVBLxfo25r7aqQ_X8vXjOOf5t=u5uG5X9EJ0a9O+cA@mail.gmail.com>
Message-ID: <SJ0PR18MB4881A2DEEF99885BCB06190B83739@SJ0PR18MB4881.namprd18.prod.outlook.com>

CopyOnWriteArrayList implements an efficient List::replaceAll so you could do something like:

====
public static void main(String[] args) {
	List<String> cowl = new CopyOnWriteArrayList<>(new String[]{"1","2","3"});
	List<String> copy = Arrays.asList(cowl.toArray(new String[0]));
	Collections.shuffle(copy);
	Iterator<String> it = copy.iterator();	
	try {
		cowl.replaceAll(e -> it.next());
	} catch (NoSuchElementException nsee) {
		throw new ConcurrentModificationException();
	}
		
	if (it.hasNext()) {
		throw new ConcurrentModificationException();
	}

	System.out.println(cowl);
}
====

Some of the non-random access branches in Collections.java could be updated to use List::replaceAll over ListIterator next/set.  Once Collections.java was using List::replaceAll you could then just wrap CopyOnWriteArrayList in a non-random access list.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Zelva Lia <jolyjdia at gmail.com>
Sent: Friday, August 19, 2022 5:49 AM
To: core-libs-dev at openjdk.org
Subject: CopyOnWriteArrayList Collection.shuffle

Hello, when shuffling the CopyOnWrite list with the standard Collections.shuffle method, performance anomalies occur, due to the fact that it calls the set method, which copies the array each time, a possible solution (crutch) is a random comparator for sorting, so sorting in COW is redefined to its own sub - blocking implementation

Another problem with Collections.shuffle is that it's not exactly thread safe because it calls the size() method; and then iterates from it, also COW does not support modification inside the iterator (works on snapshots)


COWCollectionsShuffle      0,008 ops/ms
COWListRandomSort         1,089 ops/ms
syncListCollectionsShuffle  0,950 ops/ms


From svkamath at openjdk.org  Wed Aug 24 21:03:53 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 24 Aug 2022 21:03:53 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <RsjC2uEQtXbmaikPDgIGK_b7DWr1Ev-MLm-OIKk5rek=.73ecde00-fb74-4bd7-bdfa-46bfde693333@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comments, updated test cases and microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/bcbc2f56..0f51243a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=01-02

  Stats: 75 lines in 11 files changed: 14 ins; 28 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From psandoz at openjdk.org  Wed Aug 24 21:14:23 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Aug 2022 21:14:23 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <RsjC2uEQtXbmaikPDgIGK_b7DWr1Ev-MLm-OIKk5rek=.73ecde00-fb74-4bd7-bdfa-46bfde693333@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <RsjC2uEQtXbmaikPDgIGK_b7DWr1Ev-MLm-OIKk5rek=.73ecde00-fb74-4bd7-bdfa-46bfde693333@github.com>
Message-ID: <x3L3S3JC8LcdQZ2JujdAk_FZ8s8hn3EYEG8i8nsbVLs=.e28a9e0e-9ddc-4875-b848-194a107d92bb@github.com>

On Wed, 24 Aug 2022 21:03:53 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated test cases and microbenchmark

test/jdk/java/lang/Float/Binary16ConversionNaN.java line 29:

> 27:  * @summary Verify NaN sign and significand bits are preserved across conversions
> 28:  * @run main Binary16ConversionNaN
> 29:  * @run main/othervm/timeout=600 -XX:+UnlockDiagnosticVMOptions

Do we need to specify a timeout? The tests have been running fine without intrinsics, no timeouts reports.

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 73:

> 71:           f16out[i] = Float.floatToFloat16(fin[i]);
> 72:       }
> 73:       bh.consume(f16out);

You can simplify to this:

Suggestion:

  public float floatToFloat16() {
      for (int i = 0; i < fin.length; i++) {
          f16out[i] = Float.floatToFloat16(fin[i]);
      }
      return f16out;

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Wed Aug 24 23:05:34 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 24 Aug 2022 23:05:34 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v4]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated test cases as per review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/0f51243a..7cfed790

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=02-03

  Stats: 7 lines in 3 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From psandoz at openjdk.org  Wed Aug 24 23:10:33 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Aug 2022 23:10:33 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v4]
In-Reply-To: <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com>
Message-ID: <70BYvagN3fE5tGE5vsD-pgXrLcH5qHRN0E106OloeCg=.55dc91a3-c88e-404d-b720-f34090a493f3@github.com>

On Wed, 24 Aug 2022 23:05:34 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test cases as per review comments

test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 1:

> 1: //

Can you update the copyright comment to be consistent with other source, and also correct the year to be only 2022? e.g. copy that from `Binary16Conversion.java`.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Wed Aug 24 23:48:36 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 24 Aug 2022 23:48:36 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/7cfed790..1570e244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=03-04

  Stats: 23 lines in 1 file changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From psandoz at openjdk.org  Thu Aug 25 01:05:35 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 Aug 2022 01:05:35 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
Message-ID: <_froabAuebhqaoCfObNUz1_bFdIzJ9KgOrxWuHlHbUI=.f309fd00-a4c0-4bb1-9dd5-bac5cfb9514b@github.com>

On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright comment

Java code looks good (HotSpot reviewers also need to approve).

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9781

From psandoz at openjdk.org  Thu Aug 25 01:10:21 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 Aug 2022 01:10:21 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
Message-ID: <owb8j7cJWaJ4kqZH6xfm-dmiOc6-Q2O0UsQO4H7zs6Y=.9d151ad7-c737-4e41-a4d1-af443f7611f6@github.com>

On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright comment

A general comment: since there is native runtime code to perform conversions for constants (IIRC) I think we need to some special tests to verify that works correctly (shame there is no way to leverage the Java code in such cases). It might require some advice from other HotSpot engineers, but i think we do need to follow up with another PR on that aspect.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From jason_mehrens at hotmail.com  Thu Aug 25 03:07:26 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 25 Aug 2022 03:07:26 +0000
Subject: CopyOnWriteArrayList Collection.shuffle
In-Reply-To: <CAMETwp6iUuQR0V3DxRo+i7tL8A+1iL0C-ni4VPk5UmiEwWAqvQ@mail.gmail.com>
References: <CAMETwp7LCVBLxfo25r7aqQ_X8vXjOOf5t=u5uG5X9EJ0a9O+cA@mail.gmail.com>
 <SJ0PR18MB4881A2DEEF99885BCB06190B83739@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <CAMETwp6iUuQR0V3DxRo+i7tL8A+1iL0C-ni4VPk5UmiEwWAqvQ@mail.gmail.com>
Message-ID: <SJ0PR18MB4881523A141C9288B40E91F483729@SJ0PR18MB4881.namprd18.prod.outlook.com>

COWAL::replaceAll is the method that allows you to compose read operations under the internal lock.  For example, swap can be built with a stateful UnaryOperator.

private static void swap(List l, int i, int j) {
	l.replaceAll(new UnaryOperator() {
		int cursor;
		Object tmp;
		
                //This is run while lock is held so size is frozen.
		public Object apply(Object t) { 
			if (cursor == 0) {
				if (i >= j)
					throw new IllegalArgumentException();
					
				tmp = l.get(i);
				l.get(j); //Bounds check
			}

			Object r;
			if (cursor == i) {
				r = l.get(j);
			} else if (cursor == j) {
				r = tmp;
			} else {
				r = t;
			}

			++cursor;
			return r;
		}
	});
}

This eliminates one extra internal array copy versus the Collections::swap for COWAL.  The method signature for my example swap doesn't make much sense if COWAL is mutating (add/remove) since I'm supplying indexes as arguments.  Implementing a public swap method on COWAL would have the same problem. 

Jason

________________________________________
From: Zelva Lia <jolyjdia at gmail.com>
Sent: Wednesday, August 24, 2022 5:46 PM
To: Jason Mehrens
Cc: core-libs-dev at openjdk.org
Subject: Re: CopyOnWriteArrayList Collection.shuffle

Well, yes, this is a solvable problem, albeit with additional copying, but solvable, which cannot be said about other operations (for example, swap), I lead to the fact that there are few specialized methods in COW that can work inside synchronization and cannot be synchronized with by the COWArrayList object itself, because it is synchronized with its private lock

From sviswanathan at openjdk.org  Thu Aug 25 03:18:42 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 25 Aug 2022 03:18:42 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
Message-ID: <firCQ343CaIl9G9Xq3fcvBA7q1B7xi0psDuRwFkfFKQ=.cb71ecfa-02e2-4864-b9f2-8697093775a9@github.com>

On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright comment

src/hotspot/cpu/x86/x86.ad line 1686:

> 1684:     case Op_ConvHF2F:
> 1685:       if (!VM_Version::supports_f16c() && !VM_Version::supports_evex() &&
> 1686:           !VM_Version::supports_avx512vl()) {

The condition should be:
if (!VM_Version::supports_f16c() && 
    !(VM_Version::supports_evex() && VM_Version::supports_avx512vl())) {
   return false;
}


For AVX-512 both evex and avx512vl are needed.

src/hotspot/cpu/x86/x86_64.ad line 11320:

> 11318:   ins_pipe( pipe_slow );
> 11319: %}
> 11320: 

For F2HF, good to also add optimized rule with StoreC to benefit from vcvtps2ph memory destination form of instruction.
match(Set mem (StoreC mem (ConvF2HF src)));

src/hotspot/cpu/x86/x86_64.ad line 11330:

> 11328:   ins_pipe( pipe_slow );
> 11329: %}
> 11330: 

For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction.
match(Set dst (ConvHF2F ( LoadS mem)));

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From smarks at openjdk.org  Thu Aug 25 03:46:40 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 03:46:40 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <SPeojmhJm13tBbkUPgjEo9OY7HPdnDxq9XVklKnxlzY=.5b9ce3cb-648c-41a5-b87c-61742c74a8fc@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

test/jdk/java/util/regex/whitebox/GraphemeTest.java line 30:

> 28:  * @library /lib/testlibrary/java/lang
> 29:  * @compile --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest.java
> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED --add-opens java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest

Can you use the `@modules` directive to export+open the internal module to the test?

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From smarks at openjdk.org  Thu Aug 25 03:56:34 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 03:56:34 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 258:

> 256:                     .filter(i -> boundaries.get(i) > offset)
> 257:                     .findFirst()
> 258:                     .orElse(boundaries.size() - 1);

Is it worth trying to use Collections.binarySearch() here? I think the boundaries list is in ascending sorted order, so you might be able to drop in a binarySearch() call directly. (Need to be a bit careful with negative return values.)

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From smarks at openjdk.org  Thu Aug 25 04:06:28 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 04:06:28 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <eMmxmEfOnBYX3f2wTqQE41y4yu3yLUhEqzyaA5AIwGg=.e52ee19a-8a69-49bd-a60e-25784b57b347@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

I took a quick look. Overall looks reasonable. How much scrutiny did you need?

Also, nice use of method handles.

Might be helpful to provide an example of the behavior change in the CSR.

This is probably also worth a release note documenting the behavior change and showing an example.

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From alanb at openjdk.org  Thu Aug 25 07:14:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Aug 2022 07:14:20 GMT
Subject: RFR: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
In-Reply-To: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
References: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
Message-ID: <hQqOtdyWh8IHNBvk5SU13UBTzzNf39KcaNHRumY6zAY=.965191b6-e7a1-4830-b3bc-30ad1770a270@github.com>

On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.
> 
> They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.
> 
> See the investigation on RISC-V here:
>   https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html
> 
> We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."
> 
> Additional testing:
>  - [x] Linux x86_64, `java/util/concurrent` tests

Surprising that this has lurked for 9 years without being noticed.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10002

From duke at openjdk.org  Thu Aug 25 07:49:30 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Aug 2022 07:49:30 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
Message-ID: <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>

On Sun, 21 Aug 2022 20:07:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292698: Fix copyright year

Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:

public final int readInt() throws IOException {
    readFully(readBuffer, 0, 4);
    return (readBuffer[0] & 0xff) << 24
         + (readBuffer[1] & 0xff) << 16
         + (readBuffer[2] & 0xff) << 8
         + (readBuffer[3] & 0xff);
}

but with this change the build fails with

Building target 'test' in configuration 'macosx-x86_64-server-release'
Compiling 3158 files for java.base
Updating support/src.zip
Optimizing the exploded image
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
make[3]: *** [/Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/_optimize_image_exec.marker] Error 1
make[2]: *** [exploded-image-optimize] Error 2

ERROR: Build failed for target 'test' in configuration 'macosx-x86_64-server-release' (exit code 2) 
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number

* All command lines available in /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

What is wrong with the change?

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Thu Aug 25 09:24:20 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Thu, 25 Aug 2022 09:24:20 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>

> Add support for named groups to java.util.regex.MatchResult

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8065554: MatchResult should provide values of named-capturing groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/fae689f3..d9945149

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=00-01

  Stats: 30 lines in 1 file changed: 15 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Thu Aug 25 09:24:21 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Thu, 25 Aug 2022 09:24:21 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <76go15CQnqqOT6NsAGyBstjeRWlNS_X5vRjQnEXoFOc=.75dc13ec-d174-4696-b625-a9a091d513e9@github.com>

On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> Add support for named groups to java.util.regex.MatchResult

Addressed concerns about undocumented `UnsuportedOperationException`.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From alanb at openjdk.org  Thu Aug 25 09:29:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Aug 2022 09:29:21 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
Message-ID: <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>

On Thu, 25 Aug 2022 07:46:13 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> What is wrong with the change?

You'll need parentheses to make that work, changing it to use '|' would work too.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From jdowland at openjdk.org  Thu Aug 25 09:58:45 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 09:58:45 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory
Message-ID: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>

When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.

https://bugs.openjdk.org/browse/JDK-8292541

This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
(https://github.com/openjdk/jdk/pull/9880)

-------------

Commit messages:
 - catch CgroupMetrics.getMemoryLimit exceeding physical RAM
 - Add two tests to catch deriving invalid max memory limit from cgroups

Changes: https://git.openjdk.org/jdk/pull/10017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292541
  Stats: 47 lines in 3 files changed: 47 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 10:07:15 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 10:07:15 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v2]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:

  avoid calling subsystem.getMemoryLimit twice

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10017/files
  - new: https://git.openjdk.org/jdk/pull/10017/files/668b81f7..806a0847

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From stuefe at openjdk.org  Thu Aug 25 10:14:36 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Aug 2022 10:14:36 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v2]
In-Reply-To: <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>
Message-ID: <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>

On Thu, 25 Aug 2022 10:07:15 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid calling subsystem.getMemoryLimit twice

src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 126:

> 124:         long subs_mem = subsystem.getMemoryLimit();
> 125:         // catch the cgroup memory limit exceeding host physical memory.
> 126:         // treat this as unlimited.

nit: Start sentences uppercase

src/java.base/linux/native/libjava/CgroupMetrics.c line 41:

> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
> 40:   (JNIEnv *env, jclass ignored)
> 41: {

Why not do it the same way hotspot does? 

  sysinfo(&si);
  avail_mem = (julong)si.freeram * si.mem_unit;

if for some weird reason the APIs return different numbers, at least we use the same numbers in JDK and VM.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 12:35:13 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 12:35:13 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>
 <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>
Message-ID: <wecsQkHHcjL0Rn9rumwJ8elEoY5GR1p5-mi3YockL1o=.98090226-f804-4e09-bce8-810167c35861@github.com>

On Thu, 25 Aug 2022 10:02:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address nit
>>   
>>   Thanks Thomas Stuefe
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 126:
> 
>> 124:         long subs_mem = subsystem.getMemoryLimit();
>> 125:         // catch the cgroup memory limit exceeding host physical memory.
>> 126:         // treat this as unlimited.
> 
> nit: Start sentences uppercase

Thanks - Address in ff6990cb3ec

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 12:35:13 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 12:35:13 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:

  Address nit
  
  Thanks Thomas Stuefe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10017/files
  - new: https://git.openjdk.org/jdk/pull/10017/files/806a0847..ff6990cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 12:45:25 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 12:45:25 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v2]
In-Reply-To: <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>
 <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>
Message-ID: <GWFwLeMvCtfGUxKQtNvilbaXx4HrzDxeVt9ciBYO3NU=.74a4d612-92f0-41b4-b4df-6f7a81e2a661@github.com>

On Thu, 25 Aug 2022 10:09:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid calling subsystem.getMemoryLimit twice
>
> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
> 
>> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
>> 40:   (JNIEnv *env, jclass ignored)
>> 41: {
> 
> Why not do it the same way hotspot does? 
> 
>   sysinfo(&si);
>   avail_mem = (julong)si.freeram * si.mem_unit;
> 
> if for some weird reason the APIs return different numbers, at least we use the same numbers in JDK and VM.

I don't have a strong preference for `sysconf` over `sysinfo`: The former avoids an explicit local variable but I guess that doesn't really matter. I take your point about possible divergent values from hotspot. Unfortunately there's a third example, `Java_com_sun_management_internal_OperatingSystemImpl_getFreeMemorySize0` in [src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c](https://github.com/openjdk/jdk/blob/master/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#L249) which is where I took the `sysconf` approach from.

(I don't think it is practical for the code I've changed here, `CgroupMetrics`, to re-use the existing (currently private) native method `getTotalMemorySize0` in `OperatingSystemImpl` due to circular dependency issues).

With respect to consistency with hotspot: out of scope for these two bugs, perhaps hotspot could export the data structures it populates from cgroups for internal (to the jdk) consumption, and we could avoid re-parsing the cgroup structures in Java code entirely. That would guarantee consistency and mean that the consumers benefit from e.g. the caching that the hotspot code has and this lacks. This might make a good RFE?

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From stuefe at openjdk.org  Thu Aug 25 12:54:11 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Aug 2022 12:54:11 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
Message-ID: <hNV5Aym-vfyG35m32fEyIqLMACJE4vb2rslA8AJ8Buk=.7c0ed426-5f71-49c1-bd7f-6c5d0e870740@github.com>

On Thu, 25 Aug 2022 12:35:13 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address nit
>   
>   Thanks Thomas Stuefe

LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10017

From stuefe at openjdk.org  Thu Aug 25 12:54:12 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Aug 2022 12:54:12 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v2]
In-Reply-To: <GWFwLeMvCtfGUxKQtNvilbaXx4HrzDxeVt9ciBYO3NU=.74a4d612-92f0-41b4-b4df-6f7a81e2a661@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <l7q7LcyeaSLZEck-PHhOaqeOUY2RI687-_T23xA8lFk=.41c2eb46-e179-4f9c-8f47-5e70303468c5@github.com>
 <iHxC51A4Av3fNrf8fgoD6-B9AFUcKc_PaAWjBeXV8c8=.ba1b4321-1d30-43c3-ac8c-0c4dc6fab065@github.com>
 <GWFwLeMvCtfGUxKQtNvilbaXx4HrzDxeVt9ciBYO3NU=.74a4d612-92f0-41b4-b4df-6f7a81e2a661@github.com>
Message-ID: <56mY-yV_SEIOgyZdAvUcAm36qIGa2D4xcyIqPk0fJ3Y=.9d22fe96-2a56-414f-8fa2-2b3bda236c51@github.com>

On Thu, 25 Aug 2022 12:41:31 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
>> 
>>> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
>>> 40:   (JNIEnv *env, jclass ignored)
>>> 41: {
>> 
>> Why not do it the same way hotspot does? 
>> 
>>   sysinfo(&si);
>>   avail_mem = (julong)si.freeram * si.mem_unit;
>> 
>> if for some weird reason the APIs return different numbers, at least we use the same numbers in JDK and VM.
>
> I don't have a strong preference for `sysconf` over `sysinfo`: The former avoids an explicit local variable but I guess that doesn't really matter. I take your point about possible divergent values from hotspot. Unfortunately there's a third example, `Java_com_sun_management_internal_OperatingSystemImpl_getFreeMemorySize0` in [src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c](https://github.com/openjdk/jdk/blob/master/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#L249) which is where I took the `sysconf` approach from.
> 
> (I don't think it is practical for the code I've changed here, `CgroupMetrics`, to re-use the existing (currently private) native method `getTotalMemorySize0` in `OperatingSystemImpl` due to circular dependency issues).
> 
> With respect to consistency with hotspot: out of scope for these two bugs, perhaps hotspot could export the data structures it populates from cgroups for internal (to the jdk) consumption, and we could avoid re-parsing the cgroup structures in Java code entirely. That would guarantee consistency and mean that the consumers benefit from e.g. the caching that the hotspot code has and this lacks. This might make a good RFE?

Okay, lets leave it this way. One would hope the results are identical.

> With respect to consistency with hotspot: out of scope for these two bugs, perhaps hotspot could export the data structures it populates from cgroups for internal (to the jdk) consumption, and we could avoid re-parsing the cgroup structures in Java code entirely. That would guarantee consistency and mean that the consumers benefit from e.g. the caching that the hotspot code has and this lacks. This might make a good RFE?

Possibly. Personally, I would not broaden the JVM interface for that, but I have not looked deeply enough into the java implementation to weigh in.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From sgehwolf at openjdk.org  Thu Aug 25 14:03:51 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Aug 2022 14:03:51 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
Message-ID: <o4cbAQXKSuvoKyAstMl6On7TTsXt4QDa8o4C_GIn3u8=.16f863bf-871b-4086-86b2-18f023651733@github.com>

On Thu, 25 Aug 2022 12:35:13 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address nit
>   
>   Thanks Thomas Stuefe

src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 124:

> 122:     @Override
> 123:     public long getMemoryLimit() {
> 124:         long subs_mem = subsystem.getMemoryLimit();

Style nit: `subsMem` camelcase ;-)

src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 126:

> 124:         long subs_mem = subsystem.getMemoryLimit();
> 125:         // Catch the cgroup memory limit exceeding host physical memory.
> 126:         // treat this as unlimited.

Nit: capital `T`.

src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 128:

> 126:         // treat this as unlimited.
> 127:         if (subs_mem >= getTotalMemorySize0()) {
> 128:             return -1;

Please use `CgroupSubsystem.LONG_RETVAL_UNLIMITED` instead of this magic number.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 15:35:29 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 15:35:29 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
Message-ID: <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>

On Thu, 25 Aug 2022 12:35:13 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address nit
>   
>   Thanks Thomas Stuefe

test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 53:

> 51:         DockerRunOptions opts = Common.newOpts(imageName);
> 52:         String goodMem = Common.run(opts).firstMatch("total physical memory: (\\d+)", 1);
> 53:         assertNotNull(goodMem, "no match for 'total physical memory' in trace output");

I've just realised this will not match (yet) since the relevant log line is added in #9880 .

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 16:08:11 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 16:08:11 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v4]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <Blyw7olDP6Z4-ZG4ydoQI79-w0RA5pAYOYtwqlFADeQ=.b3123200-a6f4-4447-bd78-72943b0617b6@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request incrementally with two additional commits since the last revision:

 - use pre-defined constant over magic number
 - Address style nits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10017/files
  - new: https://git.openjdk.org/jdk/pull/10017/files/ff6990cb..01d07ab4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 16:08:12 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 16:08:12 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <o4cbAQXKSuvoKyAstMl6On7TTsXt4QDa8o4C_GIn3u8=.16f863bf-871b-4086-86b2-18f023651733@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
 <o4cbAQXKSuvoKyAstMl6On7TTsXt4QDa8o4C_GIn3u8=.16f863bf-871b-4086-86b2-18f023651733@github.com>
Message-ID: <nYTL8YeA8nqGI0JbrH4oehkfVWdtzrbzCkQYgIgRJ3k=.dd44bf14-0dcf-404e-860a-7c159d6b414c@github.com>

On Thu, 25 Aug 2022 14:00:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address nit
>>   
>>   Thanks Thomas Stuefe
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 124:
> 
>> 122:     @Override
>> 123:     public long getMemoryLimit() {
>> 124:         long subs_mem = subsystem.getMemoryLimit();
> 
> Style nit: `subsMem` camelcase ;-)

Addressed in 01d07ab4b2e.

> src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 126:
> 
>> 124:         long subs_mem = subsystem.getMemoryLimit();
>> 125:         // Catch the cgroup memory limit exceeding host physical memory.
>> 126:         // treat this as unlimited.
> 
> Nit: capital `T`.

Addressed in 85fa402acbb.

> src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java line 128:
> 
>> 126:         // treat this as unlimited.
>> 127:         if (subs_mem >= getTotalMemorySize0()) {
>> 128:             return -1;
> 
> Please use `CgroupSubsystem.LONG_RETVAL_UNLIMITED` instead of this magic number.

Addressed in 01d07ab4b2e.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 16:15:53 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 16:15:53 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v5]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:

  Add a log-line for total physical memory
  
  This is relied upon for tests in
  test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10017/files
  - new: https://git.openjdk.org/jdk/pull/10017/files/01d07ab4..1bf3aa34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From sgehwolf at openjdk.org  Thu Aug 25 16:15:53 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Aug 2022 16:15:53 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v4]
In-Reply-To: <Blyw7olDP6Z4-ZG4ydoQI79-w0RA5pAYOYtwqlFADeQ=.b3123200-a6f4-4447-bd78-72943b0617b6@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <Blyw7olDP6Z4-ZG4ydoQI79-w0RA5pAYOYtwqlFADeQ=.b3123200-a6f4-4447-bd78-72943b0617b6@github.com>
Message-ID: <MCZNK_g58H5mYSR-azdhqXWVyGZ4q3gKN4huMvUWfGs=.e1ea0055-1620-4558-a9fa-3f0c71d0a791@github.com>

On Thu, 25 Aug 2022 16:08:11 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use pre-defined constant over magic number
>  - Address style nits

Looks good.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10017

From sgehwolf at openjdk.org  Thu Aug 25 16:15:54 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Aug 2022 16:15:54 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
 <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>
Message-ID: <OWcx6nJuxpQlJAu9uoDPWB-aj5rawMBptVIrULW-Ceo=.5a07c311-ca7a-4bd2-9012-bbeb33067b75@github.com>

On Thu, 25 Aug 2022 15:32:08 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address nit
>>   
>>   Thanks Thomas Stuefe
>
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 53:
> 
>> 51:         DockerRunOptions opts = Common.newOpts(imageName);
>> 52:         String goodMem = Common.run(opts).firstMatch("total physical memory: (\\d+)", 1);
>> 53:         assertNotNull(goodMem, "no match for 'total physical memory' in trace output");
> 
> I've just realised this will not match (yet) since the relevant log line is added in #9880 .

Yes. There is a feature to use dependent PRs, which could be used here. Just target `pr/9880` instead of `master`.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Thu Aug 25 16:15:54 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 16:15:54 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <OWcx6nJuxpQlJAu9uoDPWB-aj5rawMBptVIrULW-Ceo=.5a07c311-ca7a-4bd2-9012-bbeb33067b75@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
 <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>
 <OWcx6nJuxpQlJAu9uoDPWB-aj5rawMBptVIrULW-Ceo=.5a07c311-ca7a-4bd2-9012-bbeb33067b75@github.com>
Message-ID: <vFiCOeXE7FdBkZlmQqpZca-7j-c1eWP6VOEVtmOgel8=.93fa3c65-1cb1-4870-a648-cbef7674332f@github.com>

On Thu, 25 Aug 2022 16:09:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 53:
>> 
>>> 51:         DockerRunOptions opts = Common.newOpts(imageName);
>>> 52:         String goodMem = Common.run(opts).firstMatch("total physical memory: (\\d+)", 1);
>>> 53:         assertNotNull(goodMem, "no match for 'total physical memory' in trace output");
>> 
>> I've just realised this will not match (yet) since the relevant log line is added in #9880 .
>
> Yes. There is a feature to use dependent PRs, which could be used here. Just target `pr/9880` instead of `master`.

I've pushed a small excerpt of the changes from #9880 in 1bf3aa341fd93079289f11e620938e6bed40b382 to this PR in order to add the log lines that the tests depend on.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From sgehwolf at openjdk.org  Thu Aug 25 16:37:31 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Aug 2022 16:37:31 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <vFiCOeXE7FdBkZlmQqpZca-7j-c1eWP6VOEVtmOgel8=.93fa3c65-1cb1-4870-a648-cbef7674332f@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
 <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>
 <OWcx6nJuxpQlJAu9uoDPWB-aj5rawMBptVIrULW-Ceo=.5a07c311-ca7a-4bd2-9012-bbeb33067b75@github.com>
 <vFiCOeXE7FdBkZlmQqpZca-7j-c1eWP6VOEVtmOgel8=.93fa3c65-1cb1-4870-a648-cbef7674332f@github.com>
Message-ID: <4mzfvg1ofzLYo8r9B5UoNALau_obXcxGVkLLumxQrlY=.62925e96-aee2-480d-804f-a6555be9ccee@github.com>

On Thu, 25 Aug 2022 16:12:23 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> Yes. There is a feature to use dependent PRs, which could be used here. Just target `pr/9880` instead of `master`.
>
> I've pushed a small excerpt of the changes from #9880 in 1bf3aa341fd93079289f11e620938e6bed40b382 to this PR in order to add the log lines that the tests depend on.

We cannot have this in both PRs, though.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From shade at openjdk.org  Thu Aug 25 16:43:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Aug 2022 16:43:24 GMT
Subject: RFR: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
In-Reply-To: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
References: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
Message-ID: <_JdaesuuZPyrYV1BFifZ7i7HWNeOAVN4l35JgI9XikI=.38b77ff5-40b6-44f8-885c-4703a5c1ed50@github.com>

On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.
> 
> They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.
> 
> See the investigation on RISC-V here:
>   https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html
> 
> We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."
> 
> Additional testing:
>  - [x] Linux x86_64, `java/util/concurrent` tests

Thank you all!

-------------

PR: https://git.openjdk.org/jdk/pull/10002

From shade at openjdk.org  Thu Aug 25 16:52:36 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Aug 2022 16:52:36 GMT
Subject: Integrated: 8292877: java/util/concurrent/atomic/Serial.java uses
 {Double,Long}Accumulator incorrectly
In-Reply-To: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
References: <qZTilDwAn6_Jj8LNDrpEU4nXqwukkbzRpao0QRouZKQ=.a0cdca28-a9dc-4854-90b5-88856ba95f3f@github.com>
Message-ID: <T4Oi3WCeZl3iD5QpNFRtgZlQBjkPoMTOTKTw-QU9O3Y=.0776a9e4-2553-4a24-b928-8eee568b5620@github.com>

On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks the tests on some platforms even in the single-threaded case.
> 
> They use accumulators with binary plus as update function and using non-zero values as identity, which breaks once accumulators create many cells, reset their values to identity, and then apply the function over them, producing unexpected values.
> 
> See the investigation on RISC-V here:
>   https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000594.html
> 
> We can do what `DoubleAccumulator` javadocs do as the sample, namely: "For example, to maintain a running maximum value, you could supply Double::max along with Double.NEGATIVE_INFINITY as the identity."
> 
> Additional testing:
>  - [x] Linux x86_64, `java/util/concurrent` tests

This pull request has now been integrated.

Changeset: 251bff6b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/251bff6beeafcd98824dab60e9831c0175fe0689
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8292877: java/util/concurrent/atomic/Serial.java uses {Double,Long}Accumulator incorrectly

Reviewed-by: psandoz, martin, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10002

From mchhipa at openjdk.org  Thu Aug 25 16:58:29 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 25 Aug 2022 16:58:29 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v2]
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <hh8i30_4bIFgNcGOUC4CFfcbNlnw_WvJC_0yRHiW9nY=.42731d9a-1929-4c65-a4f3-b93f38295ae2@github.com>

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9906/files
  - new: https://git.openjdk.org/jdk/pull/9906/files/7bb690bf..be00c2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9906&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9906&range=00-01

  Stats: 69 lines in 1 file changed: 68 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9906/head:pull/9906

PR: https://git.openjdk.org/jdk/pull/9906

From shade at openjdk.org  Thu Aug 25 17:09:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Aug 2022 17:09:12 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v6]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <gQq5mmtCEtndg1OnYZw153qa2s-i2jQdaYKNF4_UiSw=.2b486086-ed07-4dff-80f2-dd0efb11b284@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Pull Handles.get out of the weak retry loop
 - Drop weakDelay to 1
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Rework timeouts
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Update copyrights
 - Also do Unsafe tests
 - Fix

-------------

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=05
  Stats: 951 lines in 45 files changed: 800 ins; 0 del; 151 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From duke at openjdk.org  Thu Aug 25 17:26:20 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Aug 2022 17:26:20 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
Message-ID: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>

Currently some operations of RandomAccessFile are implemented with multiple read() invocations:

public final int readInt() throws IOException {
    int ch1 = this.read();
    int ch2 = this.read();
    int ch3 = this.read();
    int ch4 = this.read();
    if ((ch1 | ch2 | ch3 | ch4) < 0)
      throw new EOFException();
    return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
}

This can be improved by using bulk reads:

public final int readInt() throws IOException {
  readFully(readBuffer, 0, 4);
  return Bits.getInt(readBuffer, 0);
}

Benchmarking:

baselile
Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op

patch
Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

-------------

Commit messages:
 - 8292937: Fix copyright
 - 8292937: Improve performance of some read operations of RandomAccessFile

Changes: https://git.openjdk.org/jdk/pull/10031/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292937
  Stats: 129 lines in 3 files changed: 96 ins; 22 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From bpb at openjdk.org  Thu Aug 25 17:34:33 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 17:34:33 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <39y-pTSZQ_59Gl_ICSbgUKQUcansaE4_dhUZIkWEnmM=.143a7c6a-6805-47ab-bd2d-bbe00a66e8ca@github.com>

On Thu, 25 Aug 2022 17:14:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

src/java.base/share/classes/java/io/RandomAccessFile.java line 78:

> 76:     private volatile boolean closed;
> 77: 
> 78:     private final byte[] readBuffer = new byte[8];

As `readBuffer` is used in multiple places without synchronization, doesn't this create a race condition?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From duke at openjdk.org  Thu Aug 25 18:16:58 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Aug 2022 18:16:58 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <orGAiL5aBtU42NVNXRd5pOAF6VaHHQMCBLKuQ9c7uMA=.0a3994d9-c7e4-4421-a1a0-32564aa0aa0d@github.com>

On Thu, 25 Aug 2022 17:14:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

Maybe you can modify the `read0` method to receive a width parameter additionally. Or we can wait for Panama and use `mmap` for this instead of JNI? Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From jdowland at openjdk.org  Thu Aug 25 18:28:55 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 25 Aug 2022 18:28:55 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v3]
In-Reply-To: <4mzfvg1ofzLYo8r9B5UoNALau_obXcxGVkLLumxQrlY=.62925e96-aee2-480d-804f-a6555be9ccee@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <s29Ujl-511Te4AKC3S68vD0i6zhuMa0btCJN6e4jXYQ=.8108d66a-78f4-4b49-a349-217f5ba96bb5@github.com>
 <_7qkFyhU8HoffPN3g1k6w2HmwNI3Ea30pDKJEwlOuiY=.a8d86ee1-0e22-4a56-b1ad-91e9de395f8b@github.com>
 <OWcx6nJuxpQlJAu9uoDPWB-aj5rawMBptVIrULW-Ceo=.5a07c311-ca7a-4bd2-9012-bbeb33067b75@github.com>
 <vFiCOeXE7FdBkZlmQqpZca-7j-c1eWP6VOEVtmOgel8=.93fa3c65-1cb1-4870-a648-cbef7674332f@github.com>
 <4mzfvg1ofzLYo8r9B5UoNALau_obXcxGVkLLumxQrlY=.62925e96-aee2-480d-804f-a6555be9ccee@github.com>
Message-ID: <GLrWkR4TqtulVnaVN_Wpyo1dGOV7PciDWZfzsI-UYF0=.20483a91-e423-46d2-91e9-eed3b77f4746@github.com>

On Thu, 25 Aug 2022 16:33:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I've pushed a small excerpt of the changes from #9880 in 1bf3aa341fd93079289f11e620938e6bed40b382 to this PR in order to add the log lines that the tests depend on.
>
> We cannot have this in both PRs, though.

Indeed: even without this addition, the other one will merge conflict with this PR (assuming this one is merged first). So I can deal with the duplication when I resolve the conflict.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From duke at openjdk.org  Thu Aug 25 19:06:55 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Aug 2022 19:06:55 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <39y-pTSZQ_59Gl_ICSbgUKQUcansaE4_dhUZIkWEnmM=.143a7c6a-6805-47ab-bd2d-bbe00a66e8ca@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <39y-pTSZQ_59Gl_ICSbgUKQUcansaE4_dhUZIkWEnmM=.143a7c6a-6805-47ab-bd2d-bbe00a66e8ca@github.com>
Message-ID: <J_ulVgut1WLGeMx3lZTdnKVgk4SA3r8M3EvmplMq_aA=.98e9d99f-d5f3-4c1d-9342-18e53d9098cd@github.com>

On Thu, 25 Aug 2022 17:31:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = this.read();
>>     int ch2 = this.read();
>>     int ch3 = this.read();
>>     int ch4 = this.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>       throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> This can be improved by using bulk reads:
>> 
>> public final int readInt() throws IOException {
>>   readFully(readBuffer, 0, 4);
>>   return Bits.getInt(readBuffer, 0);
>> }
>> 
>> Benchmarking:
>> 
>> baselile
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
>> 
>> patch
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 78:
> 
>> 76:     private volatile boolean closed;
>> 77: 
>> 78:     private final byte[] readBuffer = new byte[8];
> 
> As `readBuffer` is used in multiple places without synchronization, doesn't this create a race condition?

It does in case one deliberate accesses the same instance from multiple threads, but there are no thread-safety guarantees for RandomAccessFile. The same shared buffer approach is used in `DataInputStream` so I think we can use it here as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From duke at openjdk.org  Thu Aug 25 19:13:45 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Aug 2022 19:13:45 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <orGAiL5aBtU42NVNXRd5pOAF6VaHHQMCBLKuQ9c7uMA=.0a3994d9-c7e4-4421-a1a0-32564aa0aa0d@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <orGAiL5aBtU42NVNXRd5pOAF6VaHHQMCBLKuQ9c7uMA=.0a3994d9-c7e4-4421-a1a0-32564aa0aa0d@github.com>
Message-ID: <GGu20XFIlhqlqCa7WA1e75a5bRdjrpqET6QcODnZ1lE=.9aa346c5-72cd-4a74-a75e-85d2d391c5fe@github.com>

On Thu, 25 Aug 2022 17:58:05 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Maybe you can modify the read0 method to receive a width parameter additionally.

@merykitty sorry, I don't get it. We already have `readBytes0()` returning array. Why do we need to add a new param to `read0`?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From naoto at openjdk.org  Thu Aug 25 20:40:00 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Aug 2022 20:40:00 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <vmc1EvFEQfa4MgaDPRK4stt9c283CAZalywVmx6Ph6c=.ce84ed14-8986-49fa-87ca-79a1843533f4@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Thanks, Stuart. I will update the CSR as you suggested.
I found a couple of failures with the JCK tests. Will update the PR along with your suggestions.

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Thu Aug 25 20:40:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Aug 2022 20:40:02 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>
Message-ID: <C_0WLb81K_nI3YtKEcmeGpO_1uAXdGA9r7DbKcUpXA8=.5bf873f2-3a44-484e-a209-7eb1f062ab36@github.com>

On Thu, 25 Aug 2022 03:52:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 258:
> 
>> 256:                     .filter(i -> boundaries.get(i) > offset)
>> 257:                     .findFirst()
>> 258:                     .orElse(boundaries.size() - 1);
> 
> Is it worth trying to use Collections.binarySearch() here? I think the boundaries list is in ascending sorted order, so you might be able to drop in a binarySearch() call directly. (Need to be a bit careful with negative return values.)

Will replace this with `Collections.binarySearch()`.

> test/jdk/java/util/regex/whitebox/GraphemeTest.java line 30:
> 
>> 28:  * @library /lib/testlibrary/java/lang
>> 29:  * @compile --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest.java
>> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED --add-opens java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest
> 
> Can you use the `@modules` directive to export+open the internal module to the test?

Good point. Will use `@modules` tag.

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From mr at openjdk.org  Thu Aug 25 20:53:58 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Thu, 25 Aug 2022 20:53:58 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v11]
In-Reply-To: <z8bf7GP--Xqtcg-AdgHchgbwaHWgCNBicWkO1VUYGeU=.bfb458fe-ff96-4fe0-9347-d31ba0bfd5fa@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <z8bf7GP--Xqtcg-AdgHchgbwaHWgCNBicWkO1VUYGeU=.bfb458fe-ff96-4fe0-9347-d31ba0bfd5fa@github.com>
Message-ID: <P_lalXLoZR8QKznomsDRVqHhw50tFwsVY3Qh1PRFeh8=.991228d7-3dce-4262-8715-604cf9f30723@github.com>

On Wed, 27 Jul 2022 10:47:44 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Add apiNote to methods which return InflaterInputStreams as InputStreams
>  - Updated wording based on @JoeDarcy's CSR review
>  - Updated wording based on @LanceAndersen's review
>  - Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods
>  - Adapted wording and copyrights based on @jaikiran review
>  - Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()
>  - Extended API-doc based on reviewer feedback
>  - 8282648: Weaken the InflaterInputStream specification in order to allow faster Zip implementations

Please update the CSR once you?ve finalized the specification changes.

src/java.base/share/classes/java/net/URLConnection.java line 848:

> 846:      * last inflated byte undefined after a read operation (see {@link
> 847:      * java.util.zip.InflaterInputStream#read(byte[], int, int)
> 848:      * InflaterInputStream.read(byte[], int, int)}).

Consider this wording, which makes the danger clearer, here and elsewhere:

     * @apiNote The {@code InputStream} returned by this method can wrap an
     * {@link java.util.zip.InflaterInputStream InflaterInputStream}, whose
     * {@link java.util.zip.InflaterInputStream#read(byte[], int, int)
     * read(byte[], int, int)} method can modify any element of the output
     * buffer.

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 136:

> 134:      * are undefined (an implementation is free to change them during the inflate
> 135:      * operation). If the return value is -1 or an exception is thrown, then the content of
> 136:      * {@code b[off]} to {@code b[off+}<i>len</i>{@code -1]} is undefined.

Consider this more precise wording, both here and in `GZIPInputStream`, `ZipInputStream`, and `JarInputStream`:

     * If this method returns a nonzero integer <i>n</i> then {@code buf[off]}
     * through {@code buf[off+}<i>n</i>{@code -1]} contain the uncompressed
     * data.  The content of elements {@code buf[off+}<i>n</i>{@code ]} through
     * {@code buf[off+}<i>len</i>{@code -1]} is undefined, contrary to the
     * specification of the {@link java.io.InputStream InputStream} superclass,
     * so an implementation is free to modify these elements during the inflate
     * operation. If this method returns {@code -1} or throws an exception then
     * the content of {@code buf[off]} through {@code buf[off+}<i>len</i>{@code
     * -1]} is undefined.

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 141:

> 139:      * @param off the start offset in the destination array {@code b}
> 140:      * @param len the maximum number of bytes read
> 141:      * @return the actual number of inflated bytes, or -1 if the end of the

s/inflated bytes/bytes inflated/

-------------

Changes requested by mr (Lead).

PR: https://git.openjdk.org/jdk/pull/7986

From duke at openjdk.org  Fri Aug 26 00:05:55 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 26 Aug 2022 00:05:55 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v2]
In-Reply-To: <hh8i30_4bIFgNcGOUC4CFfcbNlnw_WvJC_0yRHiW9nY=.42731d9a-1929-4c65-a4f3-b93f38295ae2@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
 <hh8i30_4bIFgNcGOUC4CFfcbNlnw_WvJC_0yRHiW9nY=.42731d9a-1929-4c65-a4f3-b93f38295ae2@github.com>
Message-ID: <LLpaIWKgF-MPKWExfnkH1JNaNS3K85jG_sfzo6RDIQ8=.e972d370-14ff-4543-ba2c-045148f53f77@github.com>

On Thu, 25 Aug 2022 16:58:29 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

One last thing I'd like to add is the default namespace, notated as xmlns="". Since this will impact most of the existing test cases, I am fine with adding it to one of the grandchildren and testing from there.

-------------

PR: https://git.openjdk.org/jdk/pull/9906

From smarks at openjdk.org  Fri Aug 26 00:50:58 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 00:50:58 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <zQi14uUr2BupNHFVlLoml7MkvnzZGK2M6ssISvaUlLY=.d280863e-ba46-4c95-82c1-949cee9bcff9@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

src/java.base/share/classes/java/util/regex/MatchResult.java line 111:

> 109:      * The default implementation of this method throws
> 110:      * {@link UnsupportedOperationException} if {@link #namedGroups()} is not
> 111:      * overridden.

The essential thing for `@implSpec` is to describe "self-use" of methods on this object. This is important for subclassers to know whether they can inherit the default implementation or whether they should override it. It looks like `start(String)` does the following:

- calls namedGroups() to obtain a mapping from group names to group numbers, propagating UOE if namedGroups() throws it
- if `name` is not present in the group map, throws IAE
- calls `start()` on the group number obtained from the map, and returns that value

I don't think we need to go to the level of detail about whether `get` or `containsKey` is called on the map, but I think the self-calls to `namedGroups()` and `start(int)` are important.

Similar comments apply to the `@implSpec` comments of `end(String)` and `group(String)`.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Fri Aug 26 00:55:58 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 00:55:58 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <LzDEUyl-Z8u45WeMZKrAwqmpOEpyV7lUE4z9IU1mp1A=.2bdcfcc6-56e5-4ebe-8250-fcf96c5f308d@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

src/java.base/share/classes/java/util/regex/MatchResult.java line 106:

> 104:      * by {@link #namedGroups()}. It is thus sufficient to override
> 105:      * {@link #namedGroups()} for this method to work. However, overriding this
> 106:      * method directly might be preferable for performance or for other reasons.

This `@implNote` text, is repeated in three different methods. Consider moving this to the class specification. It might make it a bit easier for implementors to see a central overview instead of having this information in each method.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Fri Aug 26 01:04:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 01:04:02 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <ha6KIcHP9eNCYL6GwIIaH7X25DkyxElDah0M8PEirw0=.dd044ce1-efe8-4744-9540-ff7028ee92db@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

src/java.base/share/classes/java/util/regex/MatchResult.java line 348:

> 346:      *
> 347:      * @apiNote
> 348:      * This method must be overridden by an implementation.

This is a bit odd. It sounds like existing MatchResult implementations (outside the JDK) are now invalid. I think it really means something like, "This method must be overridden by an implementation in order to provide valid information about whether this MatchResult contains a match." I'm not sure whether saying this is necessary; it could be omitted.

Probably also needs an `@throws UnsupportedOperationException` in case the match information is unavailable.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Fri Aug 26 01:17:15 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 01:17:15 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <MzSqaJ-QW4_uVoEM-LMvH648LwzIUT6e_SuM0NRGLKg=.061b57cc-4717-432f-bff7-1bbe5c7bfc92@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

test/jdk/java/util/regex/NamedGroupsTests.java line 115:

> 113:                             r.group("noSuchGroup");
> 114:                         } catch (IllegalArgumentException e) {  // swallowing intended
> 115:                         }

If MatchResult is behind correctly, the call to `r.start("noSuchGroup")` will always throw an exception and the subsequent calls to `r.end` and `r.group` will never be executed. This potentially will miss testing of those methods.

test/jdk/java/util/regex/NamedGroupsTests.java line 128:

> 126:                 result.group("noSuchGroup");
> 127:             } catch (IllegalArgumentException e) {  // swallowing intended
> 128:             }

Similar issue here as above.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Fri Aug 26 01:22:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 01:22:02 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <c_Sef77UI5qcRZkDtFKdnubW-zqMlLa2IV7czUZVzEs=.5fa28b8e-8aae-471a-a986-c2018b1d0999@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <1fk2-gChhwwkDbXGU-mNJDpV2ih0oLqy1rXp1NRWCOQ=.9e85ebd9-9529-4a3c-b69c-5912e0d397dd@github.com>
 <_lIF2mJZGKbXMU__Je14qfzE1lzApjzaUuVAJe8Gfm8=.721b09fb-8a68-4039-be57-d56c9a3c1282@github.com>
 <nkvwXMJZ2Qux43D6SynWLafm8O3nVqdd9lyO_SGWPYs=.d814925a-5f9f-4c59-ac53-4a1b02379727@github.com>
 <c_Sef77UI5qcRZkDtFKdnubW-zqMlLa2IV7czUZVzEs=.5fa28b8e-8aae-471a-a986-c2018b1d0999@github.com>
Message-ID: <bL5v8uNpSF1wcMgXccs5a5QcbP7T7WkRH2BOyWy9w40=.f1c2543e-a45a-429b-bb9a-58bc9e83e995@github.com>

On Wed, 24 Aug 2022 18:22:42 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> In principle, yes. In practice, I see that `namedGroups` doesn't have an `@throws UnsupportedOperationException` but has an `@implSpec` that says that the default implementation throws `UnsupportedOperationException`. This seems strange to me - maybe @stuart-marks or @jddarcy can comment.
>> 
>> What I was hinting at here however is that we might want to extend the `@implSpec` of the new methods to note that these method will throw `UnsuportedOperationException` if `namedGroups` is not implemented (like the `@implSpec` of `namedGroups` does).
>
> Ah, I see.
> So what you mean is not adding another @throws clause but to either improve @implNote or, better, to add @implSpec.

I left some inline comments on the `@implSpec`. But I do think that these methods require `@throws UnsupportedOperationException` for the cases where they don't support named groups.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Fri Aug 26 01:25:57 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 01:25:57 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <wfT5GyZaTlD_RthzwEMdikOGTLi0WUFt55MnysUmFEM=.86bc8f8f-d20b-4e24-9c20-71511ef3158c@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

Overall the specs, code, and tests look pretty good. I do think some areas of the spec need updating; sorry I didn't get to this before you created the CSR.

The test is OK, but it's starting to get to the point where it would be profitable to use TEST-NG data providers to collapse some of the test cases. We have two implementations of MatchResult: one is Matcher itself, and the other is the internal implementation returned by toMatchResult(). The setup for them differs somewhat, but the assertions should all be the same. This is kind of hard to see with separate test methods for Matcher and MatchResult. The test is reasonable as it stands, but we'll see what it looks like after the cases for checking exceptions from start(String), end(String), and group(String) are expanded.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Fri Aug 26 01:52:54 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Fri, 26 Aug 2022 01:52:54 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <GGu20XFIlhqlqCa7WA1e75a5bRdjrpqET6QcODnZ1lE=.9aa346c5-72cd-4a74-a75e-85d2d391c5fe@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <orGAiL5aBtU42NVNXRd5pOAF6VaHHQMCBLKuQ9c7uMA=.0a3994d9-c7e4-4421-a1a0-32564aa0aa0d@github.com>
 <GGu20XFIlhqlqCa7WA1e75a5bRdjrpqET6QcODnZ1lE=.9aa346c5-72cd-4a74-a75e-85d2d391c5fe@github.com>
Message-ID: <eVPtqXhni_sEzvvDPKybkJcpLYkiLfL5YXFYNv3DOog=.b62510fa-24b7-42d8-94f4-bbaa14595416@github.com>

On Thu, 25 Aug 2022 19:10:19 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Maybe you can modify the `read0` method to receive a width parameter additionally. Or we can wait for Panama and use `mmap` for this instead of JNI? Thanks.
>
>> Maybe you can modify the read0 method to receive a width parameter additionally.
> 
> @merykitty sorry, I don't get it. We already have `readBytes0()` returning array. Why do we need to add a new param to `read0`?

@stsypanov `readBytes0` reads an arbitrary number of bytes and writes them to the given buffer. What I mean here is to have `read0` read 1, 2, 4 or 8 bytes then extend the result to a `jlong`, remove the need to write the result in an array.

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From duke at openjdk.org  Fri Aug 26 06:27:23 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 26 Aug 2022 06:27:23 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows enviromnent [v2]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <d4y5QXAxkI313kfYmOTHOF2W75YlSwEF9O2i2-vcPoc=.02818f36-d7bf-47b1-9eff-b6480ce90936@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/a5f38ca4..a21ab2cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=00-01

  Stats: 41 lines in 1 file changed: 41 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Fri Aug 26 06:27:24 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 26 Aug 2022 06:27:24 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows enviromnent
In-Reply-To: <eJklE7y5yypaKcs7szWx5L0yXjaXesadc1pD0EEy_QQ=.69a33f83-8e61-45e1-a079-959d4251e113@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <eJklE7y5yypaKcs7szWx5L0yXjaXesadc1pD0EEy_QQ=.69a33f83-8e61-45e1-a079-959d4251e113@github.com>
Message-ID: <icpsNPXoGXb2UUyVXq9ojTbFerSILVN3dXxFOdZ-s2M=.49bc3e0f-43e5-4881-b678-a52c74b34683@github.com>

On Fri, 8 Jul 2022 12:10:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> The change looks fine to me since in its current form the usage of `JDK_JAVA_OPTIONS` is incorrect.
> 
> Having said that and looking at the history of this file, I think, this part of the test was added to check if the `java` launcher would be able to read an environment variable (specifically the `JDK_JAVA_OPTIONS`) whose value was in `MS932` encoding, and pass it along as a correctly encoded String, all the way to the main method of the application. If we remove this section of the test, then we would be skipping that code path completely.
> 
> Perhaps this part of the test could be modified a bit to let it pass the `JDK_JAVA_OPTIONS` environment variable with a `MS932` encoded value that acts some option to the java launcher, instead of being the argument to the main method? That way, you won't have to specify the main class name in the value of the environment variable. Specifically, something like:
> 
> 
> diff --git a/test/jdk/tools/launcher/I18NArgTest.java b/test/jdk/tools/launcher/I18NArgTest.java
> index fa09736da2f..2ba724d6f1d 100644
> --- a/test/jdk/tools/launcher/I18NArgTest.java
> +++ b/test/jdk/tools/launcher/I18NArgTest.java
> @@ -97,12 +97,17 @@ public class I18NArgTest extends TestHelper {
>  
>          // Test via JDK_JAVA_OPTIONS
>          Map<String, String> env = new HashMap<>();
> -        String cmd = "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath() +
> -                " -Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath() +
> -                " -cp " + TEST_CLASSES_DIR.getAbsolutePath() +
> -                " I18NArgTest " + unicodeStr + " " + hexValue;
> -        env.put("JDK_JAVA_OPTIONS", cmd);
> -        tr = doExec(env, javaCmd);
> +        String sysPropName = "foo.bar";
> +        // pass "-Dfoo.bar=<unicodestr>" through the JDK_JAVA_OPTIONS environment variable.
> +        // we expect that system property value to be passed along to the main method with the
> +        // correct encoding
> +        String jdkJavaOpts = "-D" + sysPropName + "=" + unicodeStr;
> +        env.put("JDK_JAVA_OPTIONS", jdkJavaOpts);
> +        tr = doExec(env,javaCmd,
> +                "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath(),
> +                "-Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath(),
> +                "-cp", TEST_CLASSES_DIR.getAbsolutePath(),
> +                "I18NArgTest", unicodeStr, hexValue, sysPropName);
>          System.out.println(tr.testOutput);
>          if (!tr.isOK()) {
>              System.err.println(tr);
> @@ -125,5 +130,23 @@ public class I18NArgTest extends TestHelper {
>                  "expected:" + expected + " obtained:" + hexValue;
>              throw new RuntimeException(message);
>          }
> +        if (args.length == 3) {
> +            // verify the value of the system property matches the expected value
> +            String sysPropName = args[2];
> +            String sysPropVal = System.getProperty(sysPropName);
> +            if (sysPropVal == null) {
> +                throw new RuntimeException("Missing system property " + sysPropName);
> +            }
> +            String sysPropHexVal = "";
> +            for (int i = 0; i < sysPropVal.length(); i++) {
> +                sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
> +            }
> +            System.out.println("System property " + sysPropName + " computed hex value: "
> +                    + sysPropHexVal);
> +            if (!sysPropHexVal.equals(expected)) {
> +                throw new RuntimeException("Unexpected value in system property, expected "
> +                        + expected + ", but got " + sysPropHexVal);
> +            }
> +        }
>      }
>  }
> 
> I haven't tested this change, so you might have to experiment with it a bit. What do you think?

@jaikiran @naotoj 

I am sorry for the late response.
I added the test pattern you proposed.
According to ["Using the JDK_JAVA_OPTIONS Launcher Environment Variable"](https://docs.oracle.com/en/java/javase/18/docs/specs/man/java.html#using-the-jdk_java_options-launcher-environment-variable) at JDK 18 Documentation of Oracle, the encoding requirement for JDK_JAVA_OPTIONS environment variable is the same as the java command line on the system, so I modified the processing for determining the result of the test via JDK_JAVA_OPTIONS to use contains method in the same way as the test without JDK_JAVA_OPTIONS. Also, I added the processing to add double quotes around space or tab in system property value specified in JDK_JAVA_OPTIONS.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Fri Aug 26 06:32:35 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 26 Aug 2022 06:32:35 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows enviromnent [v3]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/a21ab2cc..4dbf952d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=01-02

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Fri Aug 26 06:46:57 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 06:46:57 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <1kNqVKuLSi11lcCGnKeqodpGrkMJkgZd1Azt3BdDC2A=.e3fb8d04-ab62-4e37-a5e8-1dbeb4e790ff@github.com>

On Thu, 25 Aug 2022 17:14:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

Sounds reasonable, let me try

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From itakiguchi at openjdk.org  Fri Aug 26 07:19:04 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 26 Aug 2022 07:19:04 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
 <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
 <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>
Message-ID: <0G_XHad3feSdDSGvK33fsCcgu7pvG3BRDYI6AyfkqZs=.e6956cb6-3a1e-4007-bcd6-198e29ee7644@github.com>

On Mon, 8 Aug 2022 09:22:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello @AlanBateman .
>> Sorry I'm late.
>> I got some responses from ICU. [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
>> I'm not sure if they're interested in the new charset...
>> 
>> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage.
>> And some other performance advantages are there on built-in charset decoder/encoder.
>> Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes?
>> We'd like to use stable conversion loop.
>
>> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage. And some other performance advantages are there on built-in charset decoder/encoder. Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes? We'd like to use stable conversion loop.
> 
> If they have ASCII compatible regions then that may be so but I haven't see any performance data published on that. Do you know if any experiments that have deployed a CharsetProvider for the EBCDIC charsets and compared the performance with the charsets that in the JDK? There may be merit in exploring adding base abstracts implementations of CharsetEncoder/CharsetDecoder to java.nio.charsets.spi to support single and double byte charsets to see how such base implementations might look, how they would help performance, and if there are any security downsides.

Hello @AlanBateman .
Sorry, I'm late.
Test result is attached (not guaranteed).

I created attached small test program, I'm not sure it's good or not

import java.nio.*;
import java.nio.charset.*;

public class tc {
  public static void main(String[] args) throws Exception {
    Charset cs = Charset.forName(args[0]);
    int cnt = Integer.parseInt(args[1]);
    boolean useCA = "1".equals(args[2]);
    boolean useBA = "1".equals(args[3]);
    CharsetEncoder ce = cs.newEncoder();
    byte[] ba = new byte[0x4000];
    for(int i = 0; i < ba.length; i++) {
      ba[i] = (byte) i;
    }
    String s = new String(ba, cs);
    char[] ca = s.toCharArray();
    ByteBuffer bb = useBA ? ByteBuffer.allocate(ca.length) : ByteBuffer.allocateDirect(ca.length);;
    CharBuffer cb = useCA ? CharBuffer.wrap(ca) : CharBuffer.wrap(s);
    System.out.println("CharBuffer.hasArray() = " + cb.hasArray());
    System.out.println("ByteBuffer.hasArray() = " + bb.hasArray());
    long start_t = System.currentTimeMillis();
    for(int i = 0; i < 200; i++) {
      ce.reset();
      bb.position(0);
      cb.position(0);
      ce.encode(cb, bb, true);
    }
    System.out.println("Warmup: "+(System.currentTimeMillis() - start_t));
    start_t = System.currentTimeMillis();
    for(int i = 0; i < cnt; i++) {
      ce.reset();
      bb.position(0);
      cb.position(0);
      ce.encode(cb, bb, true);
    }
    System.out.println("Test: "+(System.currentTimeMillis() - start_t));
  }
}


Following test result is just for my test environment
* CPU: Intel (On-premises environment), not same machine
* Executed 5 times, the values are their average 

Use following options, like
OpenJDK:
`java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1`
ICU4J
`java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`

I used jdk-20 b12
Only A/A with OpenJDK uses ArrayEncoder (ArrayDecoder) interface

| | A/A | A/B | B/A | B/B |
| -- | --: | --: | --: | --: |
| Linux (OpenJDK) | 862 | 1265 | 1838 | 1843 |
| Linux (ICU4J) | 1450 | 1410 | 1152 | 1138 |
| Windows (OpenJDK) | 921 | 1231 | 1959 | 1850 |
| Windows (ICU4J) | 1431 | 1446 | 2227 | 2265 |
| Mac (OpenJDK) | 820 | 1163 | 1799 | 1774 |
| Mac (ICU4J) | 1282 | 1242 | 994 | 1049 |

Notes:
* A/A means CharBuffer is created via char[], ByteBuffer is generated by allocate()
* A/B means CharBuffer is created via char[], ByteBuffer is generated by allocateDirect()
* B/A means CharBuffer is created via String, ByteBuffer is generated by allocate()
* B/B means CharBuffer is created via String, ByteBuffer is generated by allocateDirect()

Actually, I'm confused by this result.
Previously, I was just comparing A/A with B/B on OpenJDK's charset.
I didn't think ICU4J's result would make a difference.

Anyway, please evaluate about this result.
And please let me know if I need more investigation.

-------------

PR: https://git.openjdk.org/jdk/pull/9399

From itakiguchi at openjdk.org  Fri Aug 26 07:34:32 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 26 Aug 2022 07:34:32 GMT
Subject: RFR: 8292899: CustomTzIDCheckDST.java testcase failed on AIX platform
Message-ID: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>

After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was integrated, it failed on the AIX platform.

Error output

STDERR:
 stdout: [];
 stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Thu Aug 25 09:29:10 CEST 2022
        at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:71)
        at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:50)
]


By my investigation, `TZ=MEZ-1MESZ,M3.5.0,M10.5.0` timezone was changed to `Europe/Berlin` timezone on AIX platform.
It seems this situation is happened because older AIX did not support `MEZ-1MESZ,M3.5.0,M10.5.0` timezone by TZ environment variable.
https://www.ibm.com/support/pages/managing-time-zone-variable-posix
AIX special code was implemented into `src/java.base/unix/native/libjava/TimeZone_md.c`.
Current AIX supports `TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00` style.
I think implementation change is required. 

Some pre-submit tests are failed, but I think these are not related this change since modified parts are just for AIX platform.

-------------

Commit messages:
 - 8292899: CustomTzIDCheckDST.java testcase failed on AIX platform

Changes: https://git.openjdk.org/jdk/pull/10036/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292899
  Stats: 17 lines in 1 file changed: 11 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10036.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10036/head:pull/10036

PR: https://git.openjdk.org/jdk/pull/10036

From alanb at openjdk.org  Fri Aug 26 09:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 09:28:07 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
Message-ID: <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>

On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets.
> |Charset|Mix|SBCS|DBCS|
> | -- | -- | -- | -- |
> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
> | Korean | Cp933 | Cp833 | Cp834 |
> 
> But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets.
> 
> I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency
> |Charset|Mix|SBCS|DBCS|
> | ------------- | ------------- | ------------- | ------------- |
> | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 |
> | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** |
> | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | 
> 
> *1: Cp037 compatible

> Use following options, like OpenJDK: `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1` ICU4J `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`
> 
> Actually, I'm confused by this result. Previously, I was just comparing A/A with B/B on OpenJDK's charset. I didn't think ICU4J's result would make a difference.

My initial reaction is one of relief that the icu4j provider can be used with current JDK builds. This means there is an option should we decide to stop adding more EBCDIC charsets to the JDK.

The test uses IBM-1047 and I can't tell if the icu4j provider is used or not. Charset doesn't define a provider method but I think would be useful to print cs.getClass() or cs.getClass().getModule() so we know which Charset implementation is used. Also I think any discussion on performance would be better served with a JMH benchmark rather than a standalone test.

-------------

PR: https://git.openjdk.org/jdk/pull/9399

From sgehwolf at openjdk.org  Fri Aug 26 10:16:55 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 26 Aug 2022 10:16:55 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v5]
In-Reply-To: <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>
Message-ID: <_KzcMgXS7ks9tuvGST4X0FrJc-ta953HQ5bVrkHmH9Y=.ddd95197-a7db-4d79-974e-66615a914a8c@github.com>

On Thu, 25 Aug 2022 16:15:53 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a log-line for total physical memory
>   
>   This is relied upon for tests in
>   test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

Sorry, but this last change is a hack.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 532:

> 530:   }
> 531:   jlong phys_mem = os::Linux::physical_memory();
> 532:   log_trace(os, container)("total physical memory: " JLONG_FORMAT, phys_mem);

This won't work reliably as expected without the change in #9880 which changes what `os::Linux::physical_memory()` reports (it's set to the container limit via `OSContainer::init()` without #9880 causing weird output). I believe this should not be integrated as-is.


$ sudo podman run --rm -ti --memory 1G -v $(pwd)/./build/linux-x86_64-server-fastdebug/images/jdk:/opt/jdk:z fedora:36
[root at 7494fe07f76b /]# /opt/jdk/bin/java -Xlog:os+container=trace -version 2>&1 | grep os,container | grep 'total physical memory'
[0.001s][trace][os,container] total physical memory: 33258033152
[0.063s][trace][os,container] total physical memory: 1073741824


Yes, this works, because `firstMatch()` is being used, but it's an ugly hack which we should avoid.

-------------

Changes requested by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Fri Aug 26 10:31:05 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 10:31:05 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v5]
In-Reply-To: <_KzcMgXS7ks9tuvGST4X0FrJc-ta953HQ5bVrkHmH9Y=.ddd95197-a7db-4d79-974e-66615a914a8c@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>
 <_KzcMgXS7ks9tuvGST4X0FrJc-ta953HQ5bVrkHmH9Y=.ddd95197-a7db-4d79-974e-66615a914a8c@github.com>
Message-ID: <K8k5r3cPsdJJk8LImMGofNnk187MWdrL0DGVxmTv01E=.3be31779-26d5-40c9-8d88-f05747a3a8e2@github.com>

On Fri, 26 Aug 2022 09:46:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a log-line for total physical memory
>>   
>>   This is relied upon for tests in
>>   test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 532:
> 
>> 530:   }
>> 531:   jlong phys_mem = os::Linux::physical_memory();
>> 532:   log_trace(os, container)("total physical memory: " JLONG_FORMAT, phys_mem);
> 
> This won't work reliably as expected without the change in #9880 which changes what `os::Linux::physical_memory()` reports (it's set to the container limit via `OSContainer::init()` without #9880 causing weird output). I believe this should not be integrated as-is.
> 
> 
> $ sudo podman run --rm -ti --memory 1G -v $(pwd)/./build/linux-x86_64-server-fastdebug/images/jdk:/opt/jdk:z fedora:36
> [root at 7494fe07f76b /]# /opt/jdk/bin/java -Xlog:os+container=trace -version 2>&1 | grep os,container | grep 'total physical memory'
> [0.001s][trace][os,container] total physical memory: 33258033152
> [0.063s][trace][os,container] total physical memory: 1073741824
> 
> 
> Yes, this works, because `firstMatch()` is being used, but it's an ugly hack which we should avoid.

Fair enough. You're right, it only works because the first match is prior to cgroups overwriting the physical number. I'm happy to wait until we merge #9880.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From duke at openjdk.org  Fri Aug 26 10:36:41 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Aug 2022 10:36:41 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v3]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <ZbbsgLQoKaUVRZtYdHLI_uPwz37t_B8Z47gGXM_y8O4=.0eb9c55e-2172-47b9-9fe3-bc60ce77cb9d@github.com>

> Add support for named groups to java.util.regex.MatchResult

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8065554: MatchResult should provide values of named-capturing groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/d9945149..c4282fe4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=01-02

  Stats: 143 lines in 2 files changed: 10 ins; 36 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Fri Aug 26 10:36:43 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Aug 2022 10:36:43 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v2]
In-Reply-To: <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <hJxI1l10eIkO3DF-yaQJtTJPGLpfRdcvKGMDnklwvbQ=.3be52b56-463e-448f-906b-580cd6e7bc38@github.com>
Message-ID: <JvYeREabqet_aLr0iGy7Sb9ScI1W2PZ7mmitfrzEQOY=.8d567650-a3ec-4ba5-a014-ac7eb45b4cfe@github.com>

On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

Addressed concerns about spec details.
CSR will be updated once the discussion about the spec has settled and the wording has stabilized.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Fri Aug 26 12:10:58 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 12:10:58 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8292937: Move logic into VM side

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10031/files
  - new: https://git.openjdk.org/jdk/pull/10031/files/b147a061..faae4fc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=00-01

  Stats: 64 lines in 4 files changed: 47 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From duke at openjdk.org  Fri Aug 26 12:10:59 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 12:10:59 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile
In-Reply-To: <eVPtqXhni_sEzvvDPKybkJcpLYkiLfL5YXFYNv3DOog=.b62510fa-24b7-42d8-94f4-bbaa14595416@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <orGAiL5aBtU42NVNXRd5pOAF6VaHHQMCBLKuQ9c7uMA=.0a3994d9-c7e4-4421-a1a0-32564aa0aa0d@github.com>
 <GGu20XFIlhqlqCa7WA1e75a5bRdjrpqET6QcODnZ1lE=.9aa346c5-72cd-4a74-a75e-85d2d391c5fe@github.com>
 <eVPtqXhni_sEzvvDPKybkJcpLYkiLfL5YXFYNv3DOog=.b62510fa-24b7-42d8-94f4-bbaa14595416@github.com>
Message-ID: <0TwyzKXPvLffQAPilaxlrrCX0uQg6jq6JZBXK7hiYqg=.180b770a-fac9-49d1-ae31-a7989960748d@github.com>

On Fri, 26 Aug 2022 01:49:06 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>>> Maybe you can modify the read0 method to receive a width parameter additionally.
>> 
>> @merykitty sorry, I don't get it. We already have `readBytes0()` returning array. Why do we need to add a new param to `read0`?
>
> @stsypanov `readBytes0` reads an arbitrary number of bytes and writes them to the given buffer. What I mean here is to have `read0` read 1, 2, 4 or 8 bytes then extend the result to a `jlong`, remove the need to write the result in an array.

@merykitty Done. The new results are:

Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
RandomAccessFileReadBenchmark.readInt              1  avgt   60   340,514 ? 11,205  us/op
RandomAccessFileReadBenchmark.readInt              5  avgt   60  1244,474 ? 40,376  us/op
RandomAccessFileReadBenchmark.readLong             1  avgt   60   237,004 ? 13,055  us/op
RandomAccessFileReadBenchmark.readLong             5  avgt   60   641,820 ?  4,896  us/op
RandomAccessFileReadBenchmark.readShort            1  avgt   60   542,874 ?  3,304  us/op
RandomAccessFileReadBenchmark.readShort            5  avgt   60  2166,878 ? 30,491  us/op

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From alanb at openjdk.org  Fri Aug 26 12:58:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 12:58:51 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
Message-ID: <IQM14ucWoHOQz0q1slMl9zcim6P0lt-LyLisy5ifaa4=.35e4f824-1e8a-4bb3-84da-f19b5bf6eac4@github.com>

On Fri, 26 Aug 2022 12:10:58 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = this.read();
>>     int ch2 = this.read();
>>     int ch3 = this.read();
>>     int ch4 = this.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>       throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> This can be improved by using bulk reads:
>> 
>> public final int readInt() throws IOException {
>>   readFully(readBuffer, 0, 4);
>>   return Bits.getInt(readBuffer, 0);
>> }
>> 
>> Benchmarking:
>> 
>> baselile
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
>> 
>> patch
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292937: Move logic into VM side

src/java.base/share/native/libjava/io_util.c line 71:

> 69:     jint nread = IO_Read(fd, buf, len);
> 70:     if (nread == -1) {
> 71:         JNU_ThrowIOExceptionWithLastError(env, "Read error");

These methods are specified to throw the more specific I/O exception EOFException at EOF.

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From jdowland at openjdk.org  Fri Aug 26 13:20:58 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 13:20:58 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v6]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <VV3F2vxGfTmgYM2zz--jEmzQ8PgJqhHuCJpAVQ3_4WU=.abb53a6e-3f9d-445d-89db-df57791c5471@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Rework testContainerMemExceedsPhysical to use common hostMaxMem
   
   For 8292541, I wrote two further tests that used the same technique
   as testContainerMemExceedsPhysical to establish baseline physical
   RAM. Rework testContainerMemExceedsPhysical to use the shared
   variable hostMaxMem rather than recalculate the value itself.
 - Merge remote-tracking branch 'origin/master' into 8292541-cgroup-metrics
 - Add a log-line for total physical memory
   
   This is relied upon for tests in
   test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
 - use pre-defined constant over magic number
 - Address style nits
 - Address nit
   
   Thanks Thomas Stuefe
 - avoid calling subsystem.getMemoryLimit twice
 - catch CgroupMetrics.getMemoryLimit exceeding physical RAM
   
   Detect when the subsystem limit exceeds physical RAM and treat
   that situation as "unlimited".
   
   Add a private native method to establish physical RAM size.
   
   This presently is only likely to work on POSIX systems, but
   CgroupMetrics are Linux-specific. None the less the precise guards etc.
   may need adjusting.
 - Add two tests to catch deriving invalid max memory limit from cgroups
   
   One test for OperatingSystemMXBean and another for
   -XshowSettings:system, which exercises the Metrics sub-system.
   
   extend TestMemoryAwareness to cover OperatingSystemMXBean with bad cgroup memory limit
   
   add testMetricsIgnoresMemLimitExceedingPhysicalMemory and refactor
   
   Pull the code that establishes host physical max RAM out into a helper
   function.

-------------

Changes: https://git.openjdk.org/jdk/pull/10017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=05
  Stats: 60 lines in 3 files changed: 46 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Fri Aug 26 13:21:00 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 13:21:00 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v5]
In-Reply-To: <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <HEd5Q2BY8MHYXwwbQ-8NaPSE-m8zf0x9bXz00z7klnA=.483124ab-4d25-44ba-94c1-c480c231ebe4@github.com>
Message-ID: <VGUu3KsRpLkozH174Hr5hfpBUidmVkMhzUtwsA-QkdA=.ca029cd8-d41f-4f01-88dc-d4d4aa402228@github.com>

On Thu, 25 Aug 2022 16:15:53 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a log-line for total physical memory
>   
>   This is relied upon for tests in
>   test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

Now that #9880 has been merged the hack is gone and the tests can match against the log lines to establish base line physical RAM. There are three tests that use this now. In [cc8fdf3](https://github.com/openjdk/jdk/pull/10017/commits/cc8fdf36af5e3f75c47348d25697e8a0b496dd42) for this PR I've adjusted the first test (merged already) to share the established baseline physical RAM value rather than calculate it again.

@jerboaa WDYT now? And thanks for all your support!

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From duke at openjdk.org  Fri Aug 26 13:26:57 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 13:26:57 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <IQM14ucWoHOQz0q1slMl9zcim6P0lt-LyLisy5ifaa4=.35e4f824-1e8a-4bb3-84da-f19b5bf6eac4@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
 <IQM14ucWoHOQz0q1slMl9zcim6P0lt-LyLisy5ifaa4=.35e4f824-1e8a-4bb3-84da-f19b5bf6eac4@github.com>
Message-ID: <-XkGUsKom9gUHAM7l7OczgL6xGsVLC1CjLH1xdk5X1U=.9e711cbd-c747-4ef3-ac77-fd80aa9be939@github.com>

On Fri, 26 Aug 2022 12:56:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292937: Move logic into VM side
>
> src/java.base/share/native/libjava/io_util.c line 71:
> 
>> 69:     jint nread = IO_Read(fd, buf, len);
>> 70:     if (nread == -1) {
>> 71:         JNU_ThrowIOExceptionWithLastError(env, "Read error");
> 
> These methods are specified to throw the more specific I/O exception EOFException at EOF.

You mean this must be changed to 

JNU_ThrowByName(env, "java/io/EOFException", NULL);

?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From sgehwolf at openjdk.org  Fri Aug 26 13:35:15 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 26 Aug 2022 13:35:15 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v6]
In-Reply-To: <VV3F2vxGfTmgYM2zz--jEmzQ8PgJqhHuCJpAVQ3_4WU=.abb53a6e-3f9d-445d-89db-df57791c5471@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <VV3F2vxGfTmgYM2zz--jEmzQ8PgJqhHuCJpAVQ3_4WU=.abb53a6e-3f9d-445d-89db-df57791c5471@github.com>
Message-ID: <2MUdY2TSOXeznrOGXPgUJt-p_ZLJ9Cm7dg4Xbzsh2SI=.d54fb2cc-efe5-48b8-92f6-eb2ce44107f9@github.com>

On Fri, 26 Aug 2022 13:20:58 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Rework testContainerMemExceedsPhysical to use common hostMaxMem
>    
>    For 8292541, I wrote two further tests that used the same technique
>    as testContainerMemExceedsPhysical to establish baseline physical
>    RAM. Rework testContainerMemExceedsPhysical to use the shared
>    variable hostMaxMem rather than recalculate the value itself.
>  - Merge remote-tracking branch 'origin/master' into 8292541-cgroup-metrics
>  - Add a log-line for total physical memory
>    
>    This is relied upon for tests in
>    test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>  - use pre-defined constant over magic number
>  - Address style nits
>  - Address nit
>    
>    Thanks Thomas Stuefe
>  - avoid calling subsystem.getMemoryLimit twice
>  - catch CgroupMetrics.getMemoryLimit exceeding physical RAM
>    
>    Detect when the subsystem limit exceeds physical RAM and treat
>    that situation as "unlimited".
>    
>    Add a private native method to establish physical RAM size.
>    
>    This presently is only likely to work on POSIX systems, but
>    CgroupMetrics are Linux-specific. None the less the precise guards etc.
>    may need adjusting.
>  - Add two tests to catch deriving invalid max memory limit from cgroups
>    
>    One test for OperatingSystemMXBean and another for
>    -XshowSettings:system, which exercises the Metrics sub-system.
>    
>    extend TestMemoryAwareness to cover OperatingSystemMXBean with bad cgroup memory limit
>    
>    add testMetricsIgnoresMemLimitExceedingPhysicalMemory and refactor
>    
>    Pull the code that establishes host physical max RAM out into a helper
>    function.

test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 93:

> 91:             testOperatingSystemMXBeanIgnoresMemLimitExceedingPhysicalMemory();
> 92:             testMetricsIgnoresMemLimitExceedingPhysicalMemory();
> 93:             testContainerMemExceedsPhysical();

Could we pass `hostMaxMem` to the relevant test functions as a parameter, instead of relying on a static variable magically being set, please? It would be a good symmetry to other tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From shade at openjdk.org  Fri Aug 26 14:03:20 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:03:20 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash ignores the algorithm
 for cache checks
Message-ID: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>

Look at implementation and figure out what happens if you do:


 computeHash("SHA-1") = someHash;
 computeHash("SHA-256") = ...?


The caching method should actually check the algorithms match.

Does not seem to be a problem at this point, since we seem to be only calling that methods with "SHA-256", but this is a landmine ready to fire. 

Additional testing:
 - [x] Linux x86_64 release, `java/lang/module` tests

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10044/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292983
  Stats: 25 lines in 1 file changed: 16 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10044/head:pull/10044

PR: https://git.openjdk.org/jdk/pull/10044

From jdowland at openjdk.org  Fri Aug 26 14:06:16 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 14:06:16 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v7]
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <STh-kWuTk1FhopnRHaK2uPuPmNUMQuV-n9X5X48pJtg=.78528664-9b83-42a5-a57d-fab9c6d57581@github.com>

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:

  Pass hostMaxMem to relevant methods as a parameter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10017/files
  - new: https://git.openjdk.org/jdk/pull/10017/files/cc8fdf36..0f37be83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10017&range=05-06

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10017/head:pull/10017

PR: https://git.openjdk.org/jdk/pull/10017

From jdowland at openjdk.org  Fri Aug 26 14:06:18 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 14:06:18 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v6]
In-Reply-To: <2MUdY2TSOXeznrOGXPgUJt-p_ZLJ9Cm7dg4Xbzsh2SI=.d54fb2cc-efe5-48b8-92f6-eb2ce44107f9@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <VV3F2vxGfTmgYM2zz--jEmzQ8PgJqhHuCJpAVQ3_4WU=.abb53a6e-3f9d-445d-89db-df57791c5471@github.com>
 <2MUdY2TSOXeznrOGXPgUJt-p_ZLJ9Cm7dg4Xbzsh2SI=.d54fb2cc-efe5-48b8-92f6-eb2ce44107f9@github.com>
Message-ID: <0tU1WdLdJhKYytFU2t5NAHW9Ea4AGnjKNaNq6WdZhBc=.96a7bb16-c153-4576-b299-c22ddeee646a@github.com>

On Fri, 26 Aug 2022 13:32:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Rework testContainerMemExceedsPhysical to use common hostMaxMem
>>    
>>    For 8292541, I wrote two further tests that used the same technique
>>    as testContainerMemExceedsPhysical to establish baseline physical
>>    RAM. Rework testContainerMemExceedsPhysical to use the shared
>>    variable hostMaxMem rather than recalculate the value itself.
>>  - Merge remote-tracking branch 'origin/master' into 8292541-cgroup-metrics
>>  - Add a log-line for total physical memory
>>    
>>    This is relied upon for tests in
>>    test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>>  - use pre-defined constant over magic number
>>  - Address style nits
>>  - Address nit
>>    
>>    Thanks Thomas Stuefe
>>  - avoid calling subsystem.getMemoryLimit twice
>>  - catch CgroupMetrics.getMemoryLimit exceeding physical RAM
>>    
>>    Detect when the subsystem limit exceeds physical RAM and treat
>>    that situation as "unlimited".
>>    
>>    Add a private native method to establish physical RAM size.
>>    
>>    This presently is only likely to work on POSIX systems, but
>>    CgroupMetrics are Linux-specific. None the less the precise guards etc.
>>    may need adjusting.
>>  - Add two tests to catch deriving invalid max memory limit from cgroups
>>    
>>    One test for OperatingSystemMXBean and another for
>>    -XshowSettings:system, which exercises the Metrics sub-system.
>>    
>>    extend TestMemoryAwareness to cover OperatingSystemMXBean with bad cgroup memory limit
>>    
>>    add testMetricsIgnoresMemLimitExceedingPhysicalMemory and refactor
>>    
>>    Pull the code that establishes host physical max RAM out into a helper
>>    function.
>
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 93:
> 
>> 91:             testOperatingSystemMXBeanIgnoresMemLimitExceedingPhysicalMemory();
>> 92:             testMetricsIgnoresMemLimitExceedingPhysicalMemory();
>> 93:             testContainerMemExceedsPhysical();
> 
> Could we pass `hostMaxMem` to the relevant test functions as a parameter, instead of relying on a static variable magically being set, please? It would be a good symmetry to other tests.

Good idea! Implemented in 0f37be83ff0.

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From sgehwolf at openjdk.org  Fri Aug 26 14:11:58 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 26 Aug 2022 14:11:58 GMT
Subject: RFR: 8292541: [Metrics] Reported memory limit may exceed physical
 machine memory [v7]
In-Reply-To: <STh-kWuTk1FhopnRHaK2uPuPmNUMQuV-n9X5X48pJtg=.78528664-9b83-42a5-a57d-fab9c6d57581@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
 <STh-kWuTk1FhopnRHaK2uPuPmNUMQuV-n9X5X48pJtg=.78528664-9b83-42a5-a57d-fab9c6d57581@github.com>
Message-ID: <zbpQtlo-5Jz1DRNknwFl13qF7zlR9cw-GZhG88ye2Fw=.d7b1861c-7a69-41b0-b627-de427382535f@github.com>

On Fri, 26 Aug 2022 14:06:16 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
>> 
>> https://bugs.openjdk.org/browse/JDK-8292541
>> 
>> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass hostMaxMem to relevant methods as a parameter

OK.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10017

From shade at openjdk.org  Fri Aug 26 14:19:09 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:19:09 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v2]
In-Reply-To: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
Message-ID: <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>

> Look at implementation and figure out what happens if you do:
> 
> 
>  computeHash("SHA-1") = someHash;
>  computeHash("SHA-256") = ...?
> 
> 
> The caching method should actually check the algorithms match.
> 
> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
> 
> Additional testing:
>  - [x] Linux x86_64 release, `java/lang/module` tests

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Touchups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10044/files
  - new: https://git.openjdk.org/jdk/pull/10044/files/40f76f5b..03961f29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=00-01

  Stats: 11 lines in 1 file changed: 4 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10044/head:pull/10044

PR: https://git.openjdk.org/jdk/pull/10044

From alanb at openjdk.org  Fri Aug 26 14:19:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 14:19:11 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v2]
In-Reply-To: <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>
Message-ID: <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>

On Fri, 26 Aug 2022 14:14:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 70:

> 68:     // ConcurrentMap<String,byte[]>.
> 69:     //
> 70:     // For correctness under concurrent updates, we need to wrap the fields

The comment "If there is a significant ..." reads more like a "TODO" and can be removed.

src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 75:

> 73:         }
> 74:         final byte[] hash;
> 75:         final String algorithm;

Have you tried using a record? Also can you move the declaration of cachedHash to after the declaration of the record.

src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 154:

> 152:         CachedHash ch = cachedHash;
> 153:         if (ch != null) {
> 154:             if (ch.algorithm.equals(algorithm)) {

The nested if looks a bit strange here, you can change to:

if (ch != null & ch.algorithm.equals(algorithm))
    return ch.hash;

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 14:19:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:19:12 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v2]
In-Reply-To: <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>
 <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
Message-ID: <VadQ30whzfAzYfD8QLUBpmmJy6Kb8v1IjGRlrMj8fOM=.cb7c6025-55da-4ac5-8e87-ce566d3532c6@github.com>

On Fri, 26 Aug 2022 14:06:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 154:
> 
>> 152:         CachedHash ch = cachedHash;
>> 153:         if (ch != null) {
>> 154:             if (ch.algorithm.equals(algorithm)) {
> 
> The nested if looks a bit strange here, you can change to:
> 
> if (ch != null & ch.algorithm.equals(algorithm))
>     return ch.hash;

Already done.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 14:23:04 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:23:04 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
Message-ID: <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>

> Look at implementation and figure out what happens if you do:
> 
> 
>  computeHash("SHA-1") = someHash;
>  computeHash("SHA-256") = ...?
> 
> 
> The caching method should actually check the algorithms match.
> 
> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
> 
> Additional testing:
>  - [x] Linux x86_64 release, `java/lang/module` tests

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10044/files
  - new: https://git.openjdk.org/jdk/pull/10044/files/03961f29..4cd7399e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=01-02

  Stats: 16 lines in 1 file changed: 0 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10044/head:pull/10044

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 14:23:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:23:06 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v2]
In-Reply-To: <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>
 <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
Message-ID: <Hd7favsJRNMve4ymHlDlqbtgDDckVxovJV3SwPLsPuQ=.9208c660-2002-4df7-8bc2-96c4d3ae7666@github.com>

On Fri, 26 Aug 2022 14:14:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 70:
> 
>> 68:     // ConcurrentMap<String,byte[]>.
>> 69:     //
>> 70:     // For correctness under concurrent updates, we need to wrap the fields
> 
> The comment "If there is a significant ..." reads more like a "TODO" and can be removed.

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 14:23:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:23:08 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <vuikRlMSMycCibNoQ_o8vDY0qP-l7J1O7rPxPkokq04=.449e966c-62d4-4fa4-99b5-0ac5981dad26@github.com>
 <9kVGENYP4HLxHZgSIClX0Jyw9F1IhHW7ocU677_pWlY=.c8cc3fd8-b2e8-49b1-a6fe-3a53e7803475@github.com>
Message-ID: <-sDebbxiZea9cIHncO5JFLHryHZgDcIuk5qeHrdLw8g=.8b838a39-27f6-46af-b306-d01496bdc49a@github.com>

On Fri, 26 Aug 2022 14:06:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 75:
> 
>> 73:         }
>> 74:         final byte[] hash;
>> 75:         final String algorithm;
> 
> Have you tried using a record? Also can you move the declaration of cachedHash to after the declaration of the record.

Switched to `record`, moved.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From alanb at openjdk.org  Fri Aug 26 14:36:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 14:36:56 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
Message-ID: <bMdOEBJ78Wxvh9gLApj7SJvKi4J8ibpJYjeH5GfLHhM=.1076f800-15f9-4590-b8e8-04cfbf320c4f@github.com>

On Fri, 26 Aug 2022 14:23:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Can you make sure that you run all jar, jmod and jlink tests? Module hashes are generated at packaging time, then checked when generating the configuration in early startup.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 14:44:54 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 14:44:54 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <bMdOEBJ78Wxvh9gLApj7SJvKi4J8ibpJYjeH5GfLHhM=.1076f800-15f9-4590-b8e8-04cfbf320c4f@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
 <bMdOEBJ78Wxvh9gLApj7SJvKi4J8ibpJYjeH5GfLHhM=.1076f800-15f9-4590-b8e8-04cfbf320c4f@github.com>
Message-ID: <8IkCtedAbg2MpTeQQhJiwx7PQSBPIbjAjLhTOu07ZSU=.3d66a145-fa27-4160-b5ef-7bfae2369ffd@github.com>

On Fri, 26 Aug 2022 14:33:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you make sure that you run all jar, jmod and jlink tests? Module hashes are generated at packaging time, then checked when generating the configuration in early startup.

`java/util/jar`, `jdk/tools/jmod`, `jdk/tools/jlink` -- all fine on Linux x86_64 release.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From ethan at mccue.dev  Fri Aug 26 14:49:50 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 26 Aug 2022 10:49:50 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <114452601.24603626.1661354507336.JavaMail.zimbra@u-pem.fr>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <81053966.24568651.1661349799072.JavaMail.zimbra@u-pem.fr>
 <CA+NR86gnNvv5UkM_ViAuK1WK6cRJtk0ur=oqutCpad+LOdgs3A@mail.gmail.com>
 <114452601.24603626.1661354507336.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+NR86gP0sDQwZwixoh8Z5QHm=u1wX4ae+XHr52e4+tpCL_etg@mail.gmail.com>

All trivial collection operations scream stream api and all stream api
operations imply a full copy or at least a full scan.

> so having trouble to write this kind of code is more a feature than an
issue :)

I love all Java code equally

On Wed, Aug 24, 2022 at 11:21 AM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Ethan McCue" <ethan at mccue.dev>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"John Hendrikx" <john.hendrikx at gmail.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent: *Wednesday, August 24, 2022 4:27:01 PM
> *Subject: *Re: Proposal: Collection mutability marker interfaces
>
> > so it's perhaps better to call add() inside a try/catch on
> UnsupportedOperationException.
>
> As much as sin is wrong, sketching out what that might look like...
> forgive the toyness of the example
>
>
>
>
>
>
> VS
>
>
>
> final class Ex {
>     private Ex() {}
>
>     /*
>      * Adds the odd numbers from 1 to 10 to the List then makes all the
> odds even.
>      *
>      * Takes ownership of the list, avoids making copies if it doesn't
> need to
>      */
>     static List<Integer> addOdds(List<Integer> l) {
>         for (int i = 1; i <= 10; i++) {
>             try {
>                 l.add(i);
>             } catch (UnsupportedOperationException e) {
>                 l = new ArrayList<>(l);
>
>
> i -= 1;  // restart with an ArrayList
>
>
>             }
>         }
>
>         for (int i = 0; i < l.size(); i++) {
>             if (l.get(i) % 2 == 1) {
>                 try {
>                     l.set(i, l.get(i) + 1);
>                 } catch (UnsupportedOperationException e) {
>                     l = new ArrayList<>(l);
>                 }
>             }
>         }
>     }
> }
>
>
> as Roger said, there is no way in Java to know if the caller has not kept
> a reference (unlike Rust),
> so having trouble to write this kind of code is more a feature than an
> issue :)
>
> This kind of examples scream the Stream API, which has the correct
> semantics
>   IntStream.rangeClosed(1, 10).map(i -> i % 2 == 0? i + 1:
> i).boxed().toList()
>
> R?mi
>
>
>
>
> On Wed, Aug 24, 2022 at 10:03 AM Remi Forax <forax at univ-mlv.fr> wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Ethan McCue" <ethan at mccue.dev>
>> *To: *"John Hendrikx" <john.hendrikx at gmail.com>
>> *Cc: *"core-libs-dev" <core-libs-dev at openjdk.org>
>> *Sent: *Wednesday, August 24, 2022 3:38:26 PM
>> *Subject: *Re: Proposal: Collection mutability marker interfaces
>>
>> A use case that doesn't cover is adding to a collection.
>>
>> Say as part of a method's contract you state that you take ownership of a
>> List. You aren't going to copy even if the list is mutable.
>>
>> Later on, you may want to add to the list. Add is supported on ArrayList
>> so you don't need to copy and replace your reference, but you would if the
>> list you were given was made with List.of or Arrays.asList
>>
>>
>> You can ask if the spliterator considers the collection as immutable or
>> not,
>>   list.spliterator().hasCharacteristics(Spliterator.IMMUTABLE)
>>
>> sadly, List.of()/Map.of() does not report the spliterator characteristics
>> correctly (the spliterator implementations are inherited from
>> AbstracList/AbstractMap).
>>
>> so it's perhaps better to call add() inside a try/catch on
>> UnsupportedOperationException.
>>
>> R?mi
>>
>>
>> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com>
>> wrote:
>>
>>> Would it be an option to not make the receiver responsible for the
>>> decision whether to make a copy or not?  Instead put this burden (using
>>> default methods) on the various collections?
>>>
>>> If List/Set/Map had a method like this:
>>>
>>>      List<T> immutableCopy();  // returns a (shallow) immutable copy if
>>> list is mutable (basically always copies, unless proven otherwise)
>>>
>>> Paired with methods on Collections to prevent collections from being
>>> modified:
>>>
>>>      Collections.immutableList(List<T>)
>>>
>>> This wrapper is similar to `unmodifiableList` except it implements
>>> `immutableCopy` as `return this`.
>>>
>>> Then for the various scenario's, where `x` is an untrusted source of
>>> List with unknown status:
>>>
>>>      // Create a defensive copy; result is a private list that cannot be
>>> modified:
>>>
>>>      List<T> y = x.immutableCopy();
>>>
>>>      // Create a defensive copy for sharing, promising it won't ever
>>> change:
>>>
>>>      List<T> y = Collections.immutableList(x.immutableCopy());
>>>
>>>      // Create a defensive copy for mutating:
>>>
>>>      List<T> y = new ArrayList<>(x);  // same as always
>>>
>>>      // Create a mutable copy, modify it, then expose as immutable:
>>>
>>>      List<T> y = new ArrayList<>(x);  // same as always
>>>
>>>      y.add( <some element> );
>>>
>>>      List<T> z = Collections.immutableList(y);
>>>
>>>      y = null;  // we promise `z` won't change again by clearing the
>>> only path to mutating it!
>>>
>>> The advantage would be that this information isn't part of the type
>>> system where it can easily get lost. The actual implementation knows best
>>> whether a copy must be made or not.
>>>
>>> Of course, the immutableList wrapper can be used incorrectly and the
>>> promise here can be broken by keeping a reference to the original (mutable)
>>> list, but I think that's an acceptable trade-off.
>>>
>>> --John
>>>
>>> PS. Chosen names are just for illustration; there is some discussion as
>>> what "unmodifiable" vs "immutable" means in the context of collections that
>>> may contain elements that are mutable. In this post, immutable refers to
>>> shallow immutability .
>>> On 24/08/2022 03:24, Ethan McCue wrote:
>>>
>>> Ah, I'm an idiot.
>>>
>>> There is still a proposal here somewhere...maybe. right now non jdk
>>> lists can't participate in the special casing?
>>>
>>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com>
>>> wrote:
>>>
>>>> List.copyOf already does what you want.
>>>>
>>>>
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>>
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>>
>>>> Paul.
>>>>
>>>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > I am running into an issue with the collections framework where I
>>>> have to choose between good semantics for users and performance.
>>>> >
>>>> > Specifically I am taking a java.util.List from my users and I need to
>>>> choose to either
>>>> > * Not defensively copy and expose a potential footgun when I pass
>>>> that List to another thread
>>>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>>>> >
>>>> > What I would really want, in a nutshell, is for List.copyOf to be a
>>>> no-op when used on lists made with List.of().
>>>> >
>>>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>>>> mechanism I think could accomplish that. My goal is to share the idea a bit
>>>> more widely and to this specific audience to get feedback.
>>>> >
>>>> >
>>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>> >
>>>> > Important also for context is Ron Pressler's comment above.
>>>> > --------------
>>>> >
>>>> > What if the collections api added more marker interfaces like
>>>> RandomAccess?
>>>> >
>>>> > It's already a common thing for codebases to make explicit null
>>>> checks at error boundaries because the type system can't encode null |
>>>> List<String>.
>>>> >
>>>> > This feels like a similar problem.
>>>> > If you have a List<T> in the type system then you don't know for sure
>>>> you can call any methods on it until you check that its not null. In the
>>>> same way, there is a set of methods that you don't know at the
>>>> type/interface level if you are allowed to call.
>>>> >
>>>> > If the List is actually a __
>>>> > Then you can definitely call
>>>> > And you know other reference holders might call
>>>> > And you can confirm its this case by
>>>> > null
>>>> > no methods
>>>> > no methods
>>>> > list == null
>>>> > List.of(...)
>>>> > get, size
>>>> > get, size
>>>> > ???
>>>> > Collections.unmodifiableList(...)
>>>> > get, size
>>>> > get, size, add, set
>>>> > ???
>>>> > Arrays.asList(...)
>>>> > get, size, set
>>>> > get, size, set
>>>> > ???
>>>> > new ArrayList<>()
>>>> > get, size, add, set
>>>> > get, size, add, set
>>>> > ???
>>>> > While yes, there is no feasible way to encode these things in the
>>>> type system. Its not impossible to encode it at runtime though.
>>>> > interface FullyImmutable {
>>>> > // So you know the existence of this implies the absence
>>>> > // of the others
>>>> > default Void cantIntersect() { return null; }
>>>> > }
>>>> >
>>>> > interace MutationCapability {
>>>> > default String cantIntersect() { return ""; }
>>>> > }
>>>> >
>>>> > interface Addable extends MutationCapability {}
>>>> > interface Settable extends MutationCapability {}
>>>> >
>>>> > If the List is actually a __
>>>> > Then you can definitely call
>>>> > And you know other reference holders might call
>>>> > And you can confirm its this case by
>>>> > null
>>>> > no methods
>>>> > no methods
>>>> > list == null
>>>> > List.of(...)
>>>> > get, size
>>>> > get, size
>>>> > instanceof FullyImmutable
>>>> > Collections.unmodifiableList(...)
>>>> > get, size
>>>> > get, size, add, set
>>>> > !(instanceof Addable) && !(instanceof Settable)
>>>> > Arrays.asList(...)
>>>> > get, size, set
>>>> > get, size, set
>>>> > instanceof Settable
>>>> > new ArrayList<>()
>>>> > get, size, add, set
>>>> > get, size, add, set
>>>> > instanceof Settable && instanceof Addable
>>>> > In the same way a RandomAccess check let's implementations decide
>>>> whether they want to try an alternative algorithm or crash, some marker
>>>> "capability" interfaces would let users of a collection decide if they want
>>>> to clone what they are given before working on it.
>>>> >
>>>> >
>>>> > --------------
>>>> >
>>>> > So the applicability of this would be that the list returned by
>>>> List.of could implement FullyImmutable, signifying that there is no caller
>>>> which might have a mutable handle on the collection. Then List.of could
>>>> check for this interface and skip a copy.
>>>> >
>>>> >
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220826/b5979d4c/attachment-0001.htm>

From alanb at openjdk.org  Fri Aug 26 14:57:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 14:57:57 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
Message-ID: <D335v7rD0CMmqMdiVFCMcrp1YOCtqdisarC7LCnhLRU=.1ef14033-b472-4a6b-9e5f-135af8f92593@github.com>

On Fri, 26 Aug 2022 14:23:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 69:

> 67:     // wrap the fields updated at the same time with a record, which carries
> 68:     // the implicit final-field semantics for its members.
> 69:     private record CachedHash(byte[] hash, String algorithm) {}

The comment still seems a bit excessive, maybe drop the last bit "which carries ..." as it is not needed here.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 15:06:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 15:06:16 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v4]
In-Reply-To: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
Message-ID: <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>

> Look at implementation and figure out what happens if you do:
> 
> 
>  computeHash("SHA-1") = someHash;
>  computeHash("SHA-256") = ...?
> 
> 
> The caching method should actually check the algorithms match.
> 
> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
> 
> Additional testing:
>  - [x] Linux x86_64 release, `java/lang/module` tests

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10044/files
  - new: https://git.openjdk.org/jdk/pull/10044/files/4cd7399e..f3eb926d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10044&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10044/head:pull/10044

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Fri Aug 26 15:06:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Aug 2022 15:06:17 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v3]
In-Reply-To: <D335v7rD0CMmqMdiVFCMcrp1YOCtqdisarC7LCnhLRU=.1ef14033-b472-4a6b-9e5f-135af8f92593@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <3RNQbH7Cy9pja2TaiBTaA1Dk-LlCd4NFUEg8t-jGG30=.f1c037f8-1692-4705-8978-fcc525472ff9@github.com>
 <D335v7rD0CMmqMdiVFCMcrp1YOCtqdisarC7LCnhLRU=.1ef14033-b472-4a6b-9e5f-135af8f92593@github.com>
Message-ID: <75RxfjzudKaY2dgiR0ObqDqbmE2ePKR0NcCNBiwQdm4=.74a2b9ef-7df2-43a4-9d6a-7f7e075223a5@github.com>

On Fri, 26 Aug 2022 14:54:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java line 69:
> 
>> 67:     // wrap the fields updated at the same time with a record, which carries
>> 68:     // the implicit final-field semantics for its members.
>> 69:     private record CachedHash(byte[] hash, String algorithm) {}
> 
> The comment still seems a bit excessive, maybe drop the last bit "which carries ..." as it is not needed here.

I don't think the comment is excessive. It declares the intent to  protects from future "optimization" of flattening the record into the plain fields. But I dropped "which carries".

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From john.hendrikx at gmail.com  Fri Aug 26 15:20:54 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 26 Aug 2022 17:20:54 +0200
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
Message-ID: <1f4532c8-02e0-cb7b-2685-920b724e8317@gmail.com>


On 24/08/2022 15:38, Ethan McCue wrote:
> A use case that doesn't cover is adding to a collection.
> Say as part of a method's contract you state that you take ownership 
> of a List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on 
> ArrayList so you don't need to copy and replace your reference, but 
> you would if the list you were given was made with List.of or 
> Arrays.asList

I don't think this is a common enough use case that should be catered 
for.? It might be better handled with concurrent lists instead.

The most common use case by far is wanting to make sure a collection 
you've received is not going to be modified while you are working with 
it.? I don't think another proposal which does cover the most common 
cases should be dismissed out of hand because it doesn't support a 
rather rare use case.

--John


>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com> 
> wrote:
>
>     Would it be an option to not make the receiver responsible for the
>     decision whether to make a copy or not?? Instead put this burden
>     (using default methods) on the various collections?
>
>     If List/Set/Map had a method like this:
>
>     ???? List<T> immutableCopy();? // returns a (shallow) immutable
>     copy if list is mutable (basically always copies, unless proven
>     otherwise)
>
>     Paired with methods on Collections to prevent collections from
>     being modified:
>
>     ???? Collections.immutableList(List<T>)
>
>     This wrapper is similar to `unmodifiableList` except it implements
>     `immutableCopy` as `return this`.
>
>     Then for the various scenario's, where `x` is an untrusted source
>     of List with unknown status:
>
>     ???? // Create a defensive copy; result is a private list that
>     cannot be modified:
>
>     ???? List<T> y = x.immutableCopy();
>
>     ???? // Create a defensive copy for sharing, promising it won't
>     ever change:
>
>     ???? List<T> y = Collections.immutableList(x.immutableCopy());
>
>     ???? // Create a defensive copy for mutating:
>
>     ???? List<T> y = new ArrayList<>(x);? // same as always
>
>     ???? // Create a mutable copy, modify it, then expose as immutable:
>
>     ???? List<T> y = new ArrayList<>(x);? // same as always
>
>     ???? y.add( <some element> );
>
>     ???? List<T> z = Collections.immutableList(y);
>
>     ???? y = null;? // we promise `z` won't change again by clearing
>     the only path to mutating it!
>
>     The advantage would be that this information isn't part of the
>     type system where it can easily get lost. The actual
>     implementation knows best whether a copy must be made or not.
>
>     Of course, the immutableList wrapper can be used incorrectly and
>     the promise here can be broken by keeping a reference to the
>     original (mutable) list, but I think that's an acceptable trade-off.
>
>     --John
>
>     PS. Chosen names are just for illustration; there is some
>     discussion as what "unmodifiable" vs "immutable" means in the
>     context of collections that may contain elements that are mutable.
>     In this post, immutable refers to shallow immutability .
>
>     On 24/08/2022 03:24, Ethan McCue wrote:
>>     Ah, I'm an idiot.
>>
>>     There is still a proposal here somewhere...maybe. right now non
>>     jdk lists can't participate in the special casing?
>>
>>     On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz
>>     <paul.sandoz at oracle.com> wrote:
>>
>>         List.copyOf already does what you want.
>>
>>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>
>>         Paul.
>>
>>         > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev>
>>         wrote:
>>         >
>>         > Hi all,
>>         >
>>         > I am running into an issue with the collections framework
>>         where I have to choose between good semantics for users and
>>         performance.
>>         >
>>         > Specifically I am taking a java.util.List from my users and
>>         I need to choose to either
>>         > * Not defensively copy and expose a potential footgun when
>>         I pass that List to another thread
>>         > * Defensively copy and make my users pay an unnecessary
>>         runtime cost.
>>         >
>>         > What I would really want, in a nutshell, is for List.copyOf
>>         to be a no-op when used on lists made with List.of().
>>         >
>>         > Below the line is a pitch I wrote up on reddit 7 months ago
>>         for a mechanism I think could accomplish that. My goal is to
>>         share the idea a bit more widely and to this specific
>>         audience to get feedback.
>>         >
>>         >
>>         https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>         <https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3>
>>
>>         >
>>         > Important also for context is Ron Pressler's comment above.
>>         > --------------
>>         >
>>         > What if the collections api added more marker interfaces
>>         like RandomAccess?
>>         >
>>         > It's already a common thing for codebases to make explicit
>>         null checks at error boundaries because the type system can't
>>         encode null | List<String>.
>>         >
>>         > This feels like a similar problem.
>>         > If you have a List<T> in the type system then you don't
>>         know for sure you can call any methods on it until you check
>>         that its not null. In the same way, there is a set of methods
>>         that you don't know at the type/interface level if you are
>>         allowed to call.
>>         >
>>         > If the List is actually a __
>>         > Then you can definitely call
>>         > And you know other reference holders might call
>>         > And you can confirm its this case by
>>         > null
>>         > no methods
>>         > no methods
>>         > list == null
>>         > List.of(...)
>>         > get, size
>>         > get, size
>>         > ???
>>         > Collections.unmodifiableList(...)
>>         > get, size
>>         > get, size, add, set
>>         > ???
>>         > Arrays.asList(...)
>>         > get, size, set
>>         > get, size, set
>>         > ???
>>         > new ArrayList<>()
>>         > get, size, add, set
>>         > get, size, add, set
>>         > ???
>>         > While yes, there is no feasible way to encode these things
>>         in the type system. Its not impossible to encode it at
>>         runtime though.
>>         > interface FullyImmutable {
>>         > // So you know the existence of this implies the absence
>>         > // of the others
>>         > default Void cantIntersect() { return null; }
>>         > }
>>         >
>>         > interace MutationCapability {
>>         > default String cantIntersect() { return ""; }
>>         > }
>>         >
>>         > interface Addable extends MutationCapability {}
>>         > interface Settable extends MutationCapability {}
>>         >
>>         > If the List is actually a __
>>         > Then you can definitely call
>>         > And you know other reference holders might call
>>         > And you can confirm its this case by
>>         > null
>>         > no methods
>>         > no methods
>>         > list == null
>>         > List.of(...)
>>         > get, size
>>         > get, size
>>         > instanceof FullyImmutable
>>         > Collections.unmodifiableList(...)
>>         > get, size
>>         > get, size, add, set
>>         > !(instanceof Addable) && !(instanceof Settable)
>>         > Arrays.asList(...)
>>         > get, size, set
>>         > get, size, set
>>         > instanceof Settable
>>         > new ArrayList<>()
>>         > get, size, add, set
>>         > get, size, add, set
>>         > instanceof Settable && instanceof Addable
>>         > In the same way a RandomAccess check let's implementations
>>         decide whether they want to try an alternative algorithm or
>>         crash, some marker "capability" interfaces would let users of
>>         a collection decide if they want to clone what they are given
>>         before working on it.
>>         >
>>         >
>>         > --------------
>>         >
>>         > So the applicability of this would be that the list
>>         returned by List.of could implement FullyImmutable,
>>         signifying that there is no caller which might have a mutable
>>         handle on the collection. Then List.of could check for this
>>         interface and skip a copy.
>>         >
>>         >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220826/5865e1df/attachment-0001.htm>

From alanb at openjdk.org  Fri Aug 26 16:11:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 16:11:57 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v4]
In-Reply-To: <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
Message-ID: <s2j2E9AIFbJ83ewxu3TZstBKNn1X7THvIFrMNtDqnPs=.2dfc5b58-41df-42d4-b884-6cdd9242a292@github.com>

On Fri, 26 Aug 2022 15:06:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From jdowland at openjdk.org  Fri Aug 26 16:25:30 2022
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Fri, 26 Aug 2022 16:25:30 GMT
Subject: Integrated: 8292541: [Metrics] Reported memory limit may exceed
 physical machine memory
In-Reply-To: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
References: <OeH8Lsbj_ryYvrDDUeUdTXJxjQrtoKJVYQmqoT46F2I=.a937b0f3-1fd9-4827-9aad-e5f0a9cbc940@github.com>
Message-ID: <Tb8puqQt0DQeVb-41hbYOErvGvzjoIWEREJ6i6-Cw0c=.8a729cd4-c8a6-4204-808c-7f4721bfca77@github.com>

On Thu, 25 Aug 2022 09:50:44 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong.
> 
> https://bugs.openjdk.org/browse/JDK-8292541
> 
> This is the equivalent core-libs fix for Hotspot's [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
> (https://github.com/openjdk/jdk/pull/9880)

This pull request has now been integrated.

Changeset: 9a0d1e7c
Author:    Jonathan Dowland <jdowland at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a0d1e7ce86368cdcade713a9e220604f7d77ecf
Stats:     61 lines in 3 files changed: 45 ins; 9 del; 7 mod

8292541: [Metrics] Reported memory limit may exceed physical machine memory

Reviewed-by: stuefe, sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/10017

From mchung at openjdk.org  Fri Aug 26 16:35:58 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Aug 2022 16:35:58 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v4]
In-Reply-To: <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
Message-ID: <eyGpTVt-wEIyoZUzWD12_9m99fCp0bE2KJQDxA79KaE=.e5d1e570-4234-4d3c-8fb8-a4a2f2af9746@github.com>

On Fri, 26 Aug 2022 15:06:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments

Looks good to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10044

From naoto at openjdk.org  Fri Aug 26 16:39:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 16:39:28 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v2]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <hvxSaidNZEdjHcXgcw_Mb5GaZ2UzKWGPBK2W8Jaf9bU=.35e52112-2833-4503-b50f-ea9a09caf7ce@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Fixing JCK failures
 - Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/6396eefa..a772c3a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=00-01

  Stats: 69 lines in 5 files changed: 28 ins; 12 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

PR: https://git.openjdk.org/jdk/pull/9991

From bpb at openjdk.org  Fri Aug 26 16:42:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 16:42:55 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
Message-ID: <fPXx58Tqh8dTBYnowBttIhuPbPM_gq99LrNyJhAEBQs=.f9c2b8e1-9482-4866-b234-7e1cba81bc48@github.com>

On Fri, 26 Aug 2022 12:10:58 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = this.read();
>>     int ch2 = this.read();
>>     int ch3 = this.read();
>>     int ch4 = this.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>       throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> This can be improved by using bulk reads:
>> 
>> public final int readInt() throws IOException {
>>   readFully(readBuffer, 0, 4);
>>   return Bits.getInt(readBuffer, 0);
>> }
>> 
>> Benchmarking:
>> 
>> baselile
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
>> 
>> patch
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292937: Move logic into VM side

src/java.base/share/native/libjava/io_util.c line 82:

> 80:                ((*(buf + 1) & 0xFF) << 16) +
> 81:                ((*(buf + 2) & 0xFF) << 8) +
> 82:                ((*(buf + 3) & 0xFF));

What if the native byte order is little-endian?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From ethan at mccue.dev  Fri Aug 26 16:54:28 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 26 Aug 2022 12:54:28 -0400
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <1f4532c8-02e0-cb7b-2685-920b724e8317@gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <1f4532c8-02e0-cb7b-2685-920b724e8317@gmail.com>
Message-ID: <CA+NR86ifxrRcqYQ3UEYZgDaZPMnMiMgDD65-Ra3Um91Y_ZUaww@mail.gmail.com>

If the collections would decide whether or not to copy, I don't think just
requesting an immutable reference would be enough.

    static <E> List<E> listCopy(Collection<? extends E> coll) {
        if (coll instanceof List12 || (coll instanceof ListN && !
((ListN<?>)coll).allowNulls)) {
            return (List<E>)coll;
        } else {
            return (List<E>)List.of(coll.toArray()); // implicit nullcheck
of coll
        }
    }

The two things that List.copyOf needs to know are that the list is
immutable, but also that it isn't a variant that might contain a null.

So maybe instead of

     List<T> y = x.immutableCopy();

It could be appropriate to use the spliterator approach and request a copy
which has certain characteristics.

    static <E> List<E> listCopy(Collection<? extends E> coll) {
        if (coll instanceof List<?> list) {
            return list.copyWhere(EnumSet.of(IMMUTABLE, DISALLOW_NULLS));
        } else {
            return (List<E>)List.of(coll.toArray()); // implicit nullcheck
of coll
        }
    }

but that leaves open whether you would want to request the *presence* of
capabilities or the *absence* of them.

Maybe

    List.of().copyWhere();

Could be defined to give a list where it is immutable and nulls aren't
allowed. And then

   List.of(1, 2, 3).copyWhere(EnumSet.of(ADDABLE, NULLS_ALLOWED));

gives you a mutable copy where nulls are allowed.

This still does presume that making a copy if a capability isn't present is
the only use of knowing the capabilities - which from the conversation so
far isn't that unrealistic

On Fri, Aug 26, 2022 at 11:20 AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

>
> On 24/08/2022 15:38, Ethan McCue wrote:
>
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state that you take ownership of a
> List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on ArrayList
> so you don't need to copy and replace your reference, but you would if the
> list you were given was made with List.of or Arrays.asList
>
> I don't think this is a common enough use case that should be catered
> for.  It might be better handled with concurrent lists instead.
>
> The most common use case by far is wanting to make sure a collection
> you've received is not going to be modified while you are working with it.
> I don't think another proposal which does cover the most common cases
> should be dismissed out of hand because it doesn't support a rather rare
> use case.
> --John
>
>
>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> Would it be an option to not make the receiver responsible for the
>> decision whether to make a copy or not?  Instead put this burden (using
>> default methods) on the various collections?
>>
>> If List/Set/Map had a method like this:
>>
>>      List<T> immutableCopy();  // returns a (shallow) immutable copy if
>> list is mutable (basically always copies, unless proven otherwise)
>>
>> Paired with methods on Collections to prevent collections from being
>> modified:
>>
>>      Collections.immutableList(List<T>)
>>
>> This wrapper is similar to `unmodifiableList` except it implements
>> `immutableCopy` as `return this`.
>>
>> Then for the various scenario's, where `x` is an untrusted source of List
>> with unknown status:
>>
>>      // Create a defensive copy; result is a private list that cannot be
>> modified:
>>
>>      List<T> y = x.immutableCopy();
>>
>>      // Create a defensive copy for sharing, promising it won't ever
>> change:
>>
>>      List<T> y = Collections.immutableList(x.immutableCopy());
>>
>>      // Create a defensive copy for mutating:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      // Create a mutable copy, modify it, then expose as immutable:
>>
>>      List<T> y = new ArrayList<>(x);  // same as always
>>
>>      y.add( <some element> );
>>
>>      List<T> z = Collections.immutableList(y);
>>
>>      y = null;  // we promise `z` won't change again by clearing the only
>> path to mutating it!
>>
>> The advantage would be that this information isn't part of the type
>> system where it can easily get lost. The actual implementation knows best
>> whether a copy must be made or not.
>>
>> Of course, the immutableList wrapper can be used incorrectly and the
>> promise here can be broken by keeping a reference to the original (mutable)
>> list, but I think that's an acceptable trade-off.
>>
>> --John
>>
>> PS. Chosen names are just for illustration; there is some discussion as
>> what "unmodifiable" vs "immutable" means in the context of collections that
>> may contain elements that are mutable. In this post, immutable refers to
>> shallow immutability .
>> On 24/08/2022 03:24, Ethan McCue wrote:
>>
>> Ah, I'm an idiot.
>>
>> There is still a proposal here somewhere...maybe. right now non jdk lists
>> can't participate in the special casing?
>>
>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> List.copyOf already does what you want.
>>>
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>
>>> Paul.
>>>
>>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <ethan at mccue.dev> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I am running into an issue with the collections framework where I have
>>> to choose between good semantics for users and performance.
>>> >
>>> > Specifically I am taking a java.util.List from my users and I need to
>>> choose to either
>>> > * Not defensively copy and expose a potential footgun when I pass that
>>> List to another thread
>>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>>> >
>>> > What I would really want, in a nutshell, is for List.copyOf to be a
>>> no-op when used on lists made with List.of().
>>> >
>>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>>> mechanism I think could accomplish that. My goal is to share the idea a bit
>>> more widely and to this specific audience to get feedback.
>>> >
>>> >
>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>> >
>>> > Important also for context is Ron Pressler's comment above.
>>> > --------------
>>> >
>>> > What if the collections api added more marker interfaces like
>>> RandomAccess?
>>> >
>>> > It's already a common thing for codebases to make explicit null checks
>>> at error boundaries because the type system can't encode null |
>>> List<String>.
>>> >
>>> > This feels like a similar problem.
>>> > If you have a List<T> in the type system then you don't know for sure
>>> you can call any methods on it until you check that its not null. In the
>>> same way, there is a set of methods that you don't know at the
>>> type/interface level if you are allowed to call.
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > ???
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > ???
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > ???
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > ???
>>> > While yes, there is no feasible way to encode these things in the type
>>> system. Its not impossible to encode it at runtime though.
>>> > interface FullyImmutable {
>>> > // So you know the existence of this implies the absence
>>> > // of the others
>>> > default Void cantIntersect() { return null; }
>>> > }
>>> >
>>> > interace MutationCapability {
>>> > default String cantIntersect() { return ""; }
>>> > }
>>> >
>>> > interface Addable extends MutationCapability {}
>>> > interface Settable extends MutationCapability {}
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > instanceof FullyImmutable
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > !(instanceof Addable) && !(instanceof Settable)
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > instanceof Settable
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > instanceof Settable && instanceof Addable
>>> > In the same way a RandomAccess check let's implementations decide
>>> whether they want to try an alternative algorithm or crash, some marker
>>> "capability" interfaces would let users of a collection decide if they want
>>> to clone what they are given before working on it.
>>> >
>>> >
>>> > --------------
>>> >
>>> > So the applicability of this would be that the list returned by
>>> List.of could implement FullyImmutable, signifying that there is no caller
>>> which might have a mutable handle on the collection. Then List.of could
>>> check for this interface and skip a copy.
>>> >
>>> >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220826/eb95b087/attachment-0001.htm>

From duke at openjdk.org  Fri Aug 26 16:55:30 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 26 Aug 2022 16:55:30 GMT
Subject: RFR: JDK-8289949 Improve test coverage for XPath: operators
Message-ID: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>

Provided coverage for XPath operators. Operators include:
* Boolean operators: or, and, =, !=, <, <=, >, >=
* Number operators: +, -, *, div, mod
* Union operator: |

-------------

Commit messages:
 - Created XPathOperatorExpTest.java

Changes: https://git.openjdk.org/jdk/pull/10047/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10047&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289949
  Stats: 141 lines in 1 file changed: 141 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10047.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10047/head:pull/10047

PR: https://git.openjdk.org/jdk/pull/10047

From duke at openjdk.org  Fri Aug 26 17:06:58 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 17:06:58 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v3]
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <MptnZV1cJ5QwwLN3TD5CN_ddJTQ48k0dMb8LobaoxpM=.9cc5f58f-6c5a-4fa6-82c9-eeec3371fc19@github.com>

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:

 - 8292937: Fix exception
 - 8292937: Fix build on Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10031/files
  - new: https://git.openjdk.org/jdk/pull/10031/files/faae4fc5..defcad9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From duke at openjdk.org  Fri Aug 26 17:07:00 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 17:07:00 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <fPXx58Tqh8dTBYnowBttIhuPbPM_gq99LrNyJhAEBQs=.f9c2b8e1-9482-4866-b234-7e1cba81bc48@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
 <fPXx58Tqh8dTBYnowBttIhuPbPM_gq99LrNyJhAEBQs=.f9c2b8e1-9482-4866-b234-7e1cba81bc48@github.com>
Message-ID: <i3Jz_7rzD7pySMPdpufMhMfCntVpABCisUenJniWAxg=.c619c43f-666d-4612-9f4e-14f6a415a6c1@github.com>

On Fri, 26 Aug 2022 16:39:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292937: Move logic into VM side
>
> src/java.base/share/native/libjava/io_util.c line 82:
> 
>> 80:                ((*(buf + 1) & 0xFF) << 16) +
>> 81:                ((*(buf + 2) & 0xFF) << 8) +
>> 82:                ((*(buf + 3) & 0xFF));
> 
> What if the native byte order is little-endian?

I don't know, sorry

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From naoto at openjdk.org  Fri Aug 26 18:12:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 18:12:04 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reverting the fix to BreakIterator.isBoundary()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/a772c3a1..d2608451

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=01-02

  Stats: 32 lines in 3 files changed: 19 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Fri Aug 26 18:27:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 18:27:57 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
Message-ID: <3U41Hgu9ciWVjRgUekZs2Aeiu3tnJo7DFnT9ijwDyUM=.1ad6fd66-4e11-450a-84e9-668fc84546a7@github.com>

On Fri, 26 Aug 2022 18:12:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting the fix to BreakIterator.isBoundary()

Modified the fix according to suggestions. Also, the CSR has been updated and a release note has been drafted.

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From duke at openjdk.org  Fri Aug 26 18:31:03 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 18:31:03 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v4]
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <JXKo-CGL-ldq5JzNExPTsZbI3jvFxBRE4W1qw0xF87c=.e30da050-23ac-480f-a707-feb8e8d1ffc4@github.com>

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8292937: Fix build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10031/files
  - new: https://git.openjdk.org/jdk/pull/10031/files/defcad9b..d67dc35a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From rriggs at openjdk.org  Fri Aug 26 18:52:01 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Aug 2022 18:52:01 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v2]
In-Reply-To: <i3Jz_7rzD7pySMPdpufMhMfCntVpABCisUenJniWAxg=.c619c43f-666d-4612-9f4e-14f6a415a6c1@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <fPLPdIElT-Mmi5ml-1IttzVGSYol3KOZgA1IleXuzvU=.5aa80048-ba8c-4e0d-9a25-d370c0e5831b@github.com>
 <fPXx58Tqh8dTBYnowBttIhuPbPM_gq99LrNyJhAEBQs=.f9c2b8e1-9482-4866-b234-7e1cba81bc48@github.com>
 <i3Jz_7rzD7pySMPdpufMhMfCntVpABCisUenJniWAxg=.c619c43f-666d-4612-9f4e-14f6a415a6c1@github.com>
Message-ID: <6z8ZOFF3QW9euLudtM5uJ-t8u2RNxjQt3F4rpvIuXyg=.c0ae6fb1-1124-4e9f-861e-31b0746b0952@github.com>

On Fri, 26 Aug 2022 17:02:36 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/native/libjava/io_util.c line 82:
>> 
>>> 80:                ((*(buf + 1) & 0xFF) << 16) +
>>> 81:                ((*(buf + 2) & 0xFF) << 8) +
>>> 82:                ((*(buf + 3) & 0xFF));
>> 
>> What if the native byte order is little-endian?
>
> I don't know, sorry

The spec and implementation for RandomAccessFile is big-endian *only*.  (As is all of the file and networking stream support).

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From naoto at openjdk.org  Fri Aug 26 19:01:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 19:01:57 GMT
Subject: RFR: 8292899: CustomTzIDCheckDST.java testcase failed on AIX
 platform
In-Reply-To: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
References: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
Message-ID: <RGVghAZZdpMU51-j6Z2vcU2DvTebzKju-FgOAtzRFXU=.9efc2b3a-c239-46d0-84b7-bcd4f033401d@github.com>

On Fri, 26 Aug 2022 07:26:46 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was integrated, it failed on the AIX platform.
> 
> Error output
> 
> STDERR:
>  stdout: [];
>  stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Thu Aug 25 09:29:10 CEST 2022
>         at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:71)
>         at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:50)
> ]
> 
> 
> By my investigation, `TZ=MEZ-1MESZ,M3.5.0,M10.5.0` timezone was changed to `Europe/Berlin` timezone on AIX platform.
> It seems this situation is happened because older AIX did not support `MEZ-1MESZ,M3.5.0,M10.5.0` timezone by TZ environment variable.
> https://www.ibm.com/support/pages/managing-time-zone-variable-posix
> AIX special code was implemented into `src/java.base/unix/native/libjava/TimeZone_md.c`.
> Current AIX supports `TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00` style.
> I think implementation change is required. 
> 
> Some pre-submit tests are failed, but I think these are not related this change since modified parts are just for AIX platform.

src/java.base/unix/native/libjava/TimeZone_md.c line 589:

> 587:     // But Hotspot does not support XPG_SUS_ENV=ON.
> 588:     // Ignore daylight saving settings to calculate current time difference
> 589:     localtm.tm_isdst = 0;

Is it OK to reset it always? Could this defy the original purpose of the fix to https://bugs.openjdk.org/browse/JDK-8285838?

-------------

PR: https://git.openjdk.org/jdk/pull/10036

From rriggs at openjdk.org  Fri Aug 26 19:09:21 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Aug 2022 19:09:21 GMT
Subject: Integrated: 8291760: PipelineLeaksFD.java still fails: More or fewer
 pipes than expected
In-Reply-To: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
References: <ee7pnmb1UmjYigXpXiOF_YQWNhTc2W8xA4vT8Jy4dP4=.db1e8044-bb86-4363-ae67-cae9f3d9b771@github.com>
Message-ID: <5lY8YaM3N9730qfraaG5rCSRWvceNrxRNH_6l9FHMcw=.8ce86233-feb3-421e-b81d-a7de6368095c@github.com>

On Wed, 17 Aug 2022 15:31:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revised test to check and close all of the streams used in the pipeline.
> 
> The test now checks the content length and closes each stdout and stderr stream.
> 
> The previous technique to redirect stderr to stdout was ineffective because the fd/stream was still created in the parent process.  Created [8291986](https://bugs.openjdk.org/browse/JDK-8291986) ProcessBuilder.redirectErrorStream(true) leaves error stream available to investigate

This pull request has now been integrated.

Changeset: 4e457acd
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e457acda09be57dbb49b5c89123bf79bf81f38c
Stats:     28 lines in 2 files changed: 8 ins; 7 del; 13 mod

8291760: PipelineLeaksFD.java still fails: More or fewer pipes than expected

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9905

From rriggs at openjdk.org  Fri Aug 26 19:15:35 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Aug 2022 19:15:35 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
Message-ID: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>

CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
The extensively relies on references processing and invokes GC on a very short cycle.
The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.

The delay between gc requests is extended to 200ms and the tests pass reliably.
There are small improvements in diagnostic messages and cleanup of unused imports.

-------------

Commit messages:
 - Extended timeout between GC requests to adapt to different timing on Aarch64.
 - 8291651: CleanerTest.java fails with "Cleanable was cleaned"
 - 8291651: CleanerTest.java fails with "Cleanable was cleaned"

Changes: https://git.openjdk.org/jdk/pull/10048/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291651
  Stats: 9 lines in 1 file changed: 2 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10048/head:pull/10048

PR: https://git.openjdk.org/jdk/pull/10048

From joehw at openjdk.org  Fri Aug 26 19:41:56 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 26 Aug 2022 19:41:56 GMT
Subject: RFR: JDK-8289949 Improve test coverage for XPath: operators
In-Reply-To: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
References: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
Message-ID: <qffgicmap7kNtcyLVVYnekQL8pqB9xgzH0Ml6ML1ZlI=.a5666394-b7f5-42b8-b909-32aa94dc4b73@github.com>

On Fri, 26 Aug 2022 16:48:03 GMT, Bill Huang <duke at openjdk.org> wrote:

> Provided coverage for XPath operators. Operators include:
> * Boolean operators: or, and, =, !=, <, <=, >, >=
> * Number operators: +, -, *, div, mod
> * Union operator: |

Looks good. A few minor comments below.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathOperatorExpTest.java line 51:

> 49:     public Object[][] getOperatorExp() {
> 50:         return new Object[][]{
> 51:                 // boolean operators: or, and, =, !=, <, <=, >, >=

boolean and relational operators

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathOperatorExpTest.java line 58:

> 56:                 {"count(//Customer[Age >= 0][Age <= 0])", 1.0},
> 57:                 {"count(//Customer[Age > 0 or Age < 0])", 2.0},
> 58:                 {"count(//Customer[Age != 0])", 2.0},

might be better for 'count' to return an integer.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathOperatorExpTest.java line 60:

> 58:                 {"count(//Customer[Age != 0])", 2.0},
> 59: 
> 60:                 // number operators: +, -, *, div, mod

arithmetic operators

-------------

PR: https://git.openjdk.org/jdk/pull/10047

From smarks at openjdk.org  Fri Aug 26 20:36:57 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 20:36:57 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v3]
In-Reply-To: <ZbbsgLQoKaUVRZtYdHLI_uPwz37t_B8Z47gGXM_y8O4=.0eb9c55e-2172-47b9-9fe3-bc60ce77cb9d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <ZbbsgLQoKaUVRZtYdHLI_uPwz37t_B8Z47gGXM_y8O4=.0eb9c55e-2172-47b9-9fe3-bc60ce77cb9d@github.com>
Message-ID: <2zjm8hxLAYsQ-5EjWpHXcIdSBkUTa4VREmtAK6Y4xPc=.f6aa7a99-df31-4069-b7e8-77d4ea5a9a11@github.com>

On Fri, 26 Aug 2022 10:36:41 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

Good updates to the test, the `@throws` clauses, and the `@implNote` in the class specification. I don't know if I was clear before, but all the new default methods require `@implSpec` clauses that explain in some detail what they do, in particular self-use -- see my [previous comment](https://github.com/openjdk/jdk/pull/10000#discussion_r955530412). (Or maybe you're still working on this.)

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Fri Aug 26 20:59:57 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Aug 2022 20:59:57 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v5]
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:

 - 8292937: Fix error C2057
 - 8292937: Remove unused method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10031/files
  - new: https://git.openjdk.org/jdk/pull/10031/files/d67dc35a..9a9a0b04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=03-04

  Stats: 25 lines in 2 files changed: 15 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From smarks at openjdk.org  Fri Aug 26 21:00:55 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 21:00:55 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
Message-ID: <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>

On Fri, 26 Aug 2022 18:12:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting the fix to BreakIterator.isBoundary()

src/java.base/share/classes/java/text/BreakIterator.java line 107:

> 105:  * <a href="https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries">
> 106:  * Grapheme Cluster Boundaries</a> section in the Unicode Standard Annex #29.
> 107:  *

I would say this is an `@implSpec` instead of an `@implNote` because we want applications to be able to rely on this behavior if they're using the default implementation. Also please make corresponding update to the CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From john.hendrikx at gmail.com  Fri Aug 26 21:04:48 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 26 Aug 2022 23:04:48 +0200
Subject: Proposal: Collection mutability marker interfaces
In-Reply-To: <CA+NR86ifxrRcqYQ3UEYZgDaZPMnMiMgDD65-Ra3Um91Y_ZUaww@mail.gmail.com>
References: <CA+NR86j7em9LFQ-uBvb9Kyid9qNznLQAzm_5fuiZi9hQQkck2w@mail.gmail.com>
 <1C8B3876-1EB6-49FE-B114-735AD9AFBBFE@oracle.com>
 <CA+NR86jY8irHa+CxUgLAGH12=vmL3kBY4xzcNkqFjN+n5gbVTw@mail.gmail.com>
 <9df8ccc5-a855-f26c-b7fd-f7a57983a701@gmail.com>
 <CA+NR86jJrzNdpVPNVkOrApZ8uw3EorPC5WL-Gz=SkgbwzH2ZDA@mail.gmail.com>
 <1f4532c8-02e0-cb7b-2685-920b724e8317@gmail.com>
 <CA+NR86ifxrRcqYQ3UEYZgDaZPMnMiMgDD65-Ra3Um91Y_ZUaww@mail.gmail.com>
Message-ID: <c02ed1a3-cf6e-93e4-6a3d-f0ab43932001@gmail.com>


On 26/08/2022 18:54, Ethan McCue wrote:
> If the collections would decide whether or not to copy, I don't think 
> just requesting an immutable reference would be enough.
>
> ? ? static <E> List<E> listCopy(Collection<? extends E> coll) {
> ? ? ? ? if (coll instanceof List12 || (coll instanceof ListN && ! 
> ((ListN<?>)coll).allowNulls)) {
> ? ? ? ? ? ? return (List<E>)coll;
> ? ? ? ? } else {
> ? ? ? ? ? ? return (List<E>)List.of(coll.toArray()); // implicit 
> nullcheck of coll
> ? ? ? ? }
> ? ? }
>
> The two things that List.copyOf needs to know are that the list is 
> immutable, but also that it isn't a variant that might contain a null.

I really don't care about the null problem, that's a problem that the 
designers of this basically brought upon themselves, not because of any 
real inherit limitation that an immutable collection can't contain 
`null`. What irks even more is that the `List` interface provides no way 
to determine if an implementation is actively null hostile meaning that 
this code is no longer safe (or strictly, never really was safe due to 
rather weak guarantees made in the `List` interface):

 ????? List<?> aList = ... ; // a list from somewhere

 ????? if (aList.contains(null)) throw IllegalArgumentException();?? // 
this is unsafe, and will cause a NPE depending on the list type

This unfortunate choice was never that visible, but since `List.of` it 
occurs more frequently in standard code, and highlights that a leniently 
specified interface is mostly a useless interface.

So, I don't see the reason to jump through hoops to use the same type of 
`List` that `List.of` or `List.copyOf` returns.? All that is required is 
that an immutable list is returned, which can be as simple as:

 ????? return Collections.unmodifiableList(clone());

Or:

 ????? return Collections.unmodifiableList(new ArrayList<>(this));

Or if already wrapped in the immutable wrapper simply `return this`.

>
> So maybe instead of
>
> ? ? ?List<T> y = x.immutableCopy();
>
> It could be appropriate to use the spliterator approach and request a 
> copy which has certain characteristics.
>
> ? ? static <E> List<E> listCopy(Collection<? extends E> coll) {
> ? ? ? ? if (coll instanceof List<?> list) {
> ? ? ? ? ? ? return list.copyWhere(EnumSet.of(IMMUTABLE, DISALLOW_NULLS));
> ? ? ? ? } else {
> ? ? ? ? ? ? return (List<E>)List.of(coll.toArray()); // implicit 
> nullcheck of coll
> ? ? ? ? }
> ? ? }
>
> but that leaves open whether you would want to request the *presence* 
> of capabilities or the *absence* of them.
>
> Maybe
>
> ? ? List.of().copyWhere();
>
> Could be defined to give a list where it is immutable and nulls aren't 
> allowed. And then
>
> ? ?List.of(1, 2, 3).copyWhere(EnumSet.of(ADDABLE, NULLS_ALLOWED));
>
> gives you a mutable?copy where nulls are allowed.
>
> This still does presume that making a copy if a capability isn't 
> present is the only use of knowing the capabilities - which from the 
> conversation so far isn't that unrealistic

I fear there are too many possibilities here to cover all use cases one 
could think of: Appendable, Prependable, Insertable, Removable, Popable, 
HeadRemovable(?), Permutable, Replacable, just to name a few.? A copy to 
create a modifiable version seems sufficient, and a custom solution is 
probably in order if that would cause performance issues (like a wrapper 
around an actual list that only allows specific functionality, like 
implements Appendable<T>).

Perhaps with a method (or constructor) of the form:

 ????? <T extends List<T> & Appendable<T>> void giveMeAnAppendableList(T 
appendable);

--John

>
> On Fri, Aug 26, 2022 at 11:20 AM John Hendrikx 
> <john.hendrikx at gmail.com> wrote:
>
>
>     On 24/08/2022 15:38, Ethan McCue wrote:
>>     A use case that doesn't cover is adding to a collection.
>>     Say as part of a method's contract you state that you take
>>     ownership of a List. You aren't going to copy even if the list is
>>     mutable.
>>
>>     Later on, you may want to add to the list. Add is supported on
>>     ArrayList so you don't need to copy and replace your reference,
>>     but you would if the list you were given was made with List.of or
>>     Arrays.asList
>
>     I don't think this is a common enough use case that should be
>     catered for.? It might be better handled with concurrent lists
>     instead.
>
>     The most common use case by far is wanting to make sure a
>     collection you've received is not going to be modified while you
>     are working with it.? I don't think another proposal which does
>     cover the most common cases should be dismissed out of hand
>     because it doesn't support a rather rare use case.
>
>     --John
>
>
>>
>>     On Wed, Aug 24, 2022, 8:13 AM John Hendrikx
>>     <john.hendrikx at gmail.com> wrote:
>>
>>         Would it be an option to not make the receiver responsible
>>         for the decision whether to make a copy or not?? Instead put
>>         this burden (using default methods) on the various collections?
>>
>>         If List/Set/Map had a method like this:
>>
>>         ???? List<T> immutableCopy();? // returns a (shallow)
>>         immutable copy if list is mutable (basically always copies,
>>         unless proven otherwise)
>>
>>         Paired with methods on Collections to prevent collections
>>         from being modified:
>>
>>         ???? Collections.immutableList(List<T>)
>>
>>         This wrapper is similar to `unmodifiableList` except it
>>         implements `immutableCopy` as `return this`.
>>
>>         Then for the various scenario's, where `x` is an untrusted
>>         source of List with unknown status:
>>
>>         ???? // Create a defensive copy; result is a private list
>>         that cannot be modified:
>>
>>         ???? List<T> y = x.immutableCopy();
>>
>>         ???? // Create a defensive copy for sharing, promising it
>>         won't ever change:
>>
>>         ???? List<T> y = Collections.immutableList(x.immutableCopy());
>>
>>         ???? // Create a defensive copy for mutating:
>>
>>         ???? List<T> y = new ArrayList<>(x); // same as always
>>
>>         ???? // Create a mutable copy, modify it, then expose as
>>         immutable:
>>
>>         ???? List<T> y = new ArrayList<>(x); // same as always
>>
>>         ???? y.add( <some element> );
>>
>>         ???? List<T> z = Collections.immutableList(y);
>>
>>         ???? y = null;? // we promise `z` won't change again by
>>         clearing the only path to mutating it!
>>
>>         The advantage would be that this information isn't part of
>>         the type system where it can easily get lost. The actual
>>         implementation knows best whether a copy must be made or not.
>>
>>         Of course, the immutableList wrapper can be used incorrectly
>>         and the promise here can be broken by keeping a reference to
>>         the original (mutable) list, but I think that's an acceptable
>>         trade-off.
>>
>>         --John
>>
>>         PS. Chosen names are just for illustration; there is some
>>         discussion as what "unmodifiable" vs "immutable" means in the
>>         context of collections that may contain elements that are
>>         mutable. In this post, immutable refers to shallow immutability .
>>
>>         On 24/08/2022 03:24, Ethan McCue wrote:
>>>         Ah, I'm an idiot.
>>>
>>>         There is still a proposal here somewhere...maybe. right now
>>>         non jdk lists can't participate in the special casing?
>>>
>>>         On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz
>>>         <paul.sandoz at oracle.com> wrote:
>>>
>>>             List.copyOf already does what you want.
>>>
>>>             https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>             https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>
>>>             Paul.
>>>
>>>             > On Aug 23, 2022, at 4:49 PM, Ethan McCue
>>>             <ethan at mccue.dev> wrote:
>>>             >
>>>             > Hi all,
>>>             >
>>>             > I am running into an issue with the collections
>>>             framework where I have to choose between good semantics
>>>             for users and performance.
>>>             >
>>>             > Specifically I am taking a java.util.List from my
>>>             users and I need to choose to either
>>>             > * Not defensively copy and expose a potential footgun
>>>             when I pass that List to another thread
>>>             > * Defensively copy and make my users pay an
>>>             unnecessary runtime cost.
>>>             >
>>>             > What I would really want, in a nutshell, is for
>>>             List.copyOf to be a no-op when used on lists made with
>>>             List.of().
>>>             >
>>>             > Below the line is a pitch I wrote up on reddit 7
>>>             months ago for a mechanism I think could accomplish
>>>             that. My goal is to share the idea a bit more widely and
>>>             to this specific audience to get feedback.
>>>             >
>>>             >
>>>             https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>>             <https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3>
>>>
>>>             >
>>>             > Important also for context is Ron Pressler's comment
>>>             above.
>>>             > --------------
>>>             >
>>>             > What if the collections api added more marker
>>>             interfaces like RandomAccess?
>>>             >
>>>             > It's already a common thing for codebases to make
>>>             explicit null checks at error boundaries because the
>>>             type system can't encode null | List<String>.
>>>             >
>>>             > This feels like a similar problem.
>>>             > If you have a List<T> in the type system then you
>>>             don't know for sure you can call any methods on it until
>>>             you check that its not null. In the same way, there is a
>>>             set of methods that you don't know at the type/interface
>>>             level if you are allowed to call.
>>>             >
>>>             > If the List is actually a __
>>>             > Then you can definitely call
>>>             > And you know other reference holders might call
>>>             > And you can confirm its this case by
>>>             > null
>>>             > no methods
>>>             > no methods
>>>             > list == null
>>>             > List.of(...)
>>>             > get, size
>>>             > get, size
>>>             > ???
>>>             > Collections.unmodifiableList(...)
>>>             > get, size
>>>             > get, size, add, set
>>>             > ???
>>>             > Arrays.asList(...)
>>>             > get, size, set
>>>             > get, size, set
>>>             > ???
>>>             > new ArrayList<>()
>>>             > get, size, add, set
>>>             > get, size, add, set
>>>             > ???
>>>             > While yes, there is no feasible way to encode these
>>>             things in the type system. Its not impossible to encode
>>>             it at runtime though.
>>>             > interface FullyImmutable {
>>>             > // So you know the existence of this implies the absence
>>>             > // of the others
>>>             > default Void cantIntersect() { return null; }
>>>             > }
>>>             >
>>>             > interace MutationCapability {
>>>             > default String cantIntersect() { return ""; }
>>>             > }
>>>             >
>>>             > interface Addable extends MutationCapability {}
>>>             > interface Settable extends MutationCapability {}
>>>             >
>>>             > If the List is actually a __
>>>             > Then you can definitely call
>>>             > And you know other reference holders might call
>>>             > And you can confirm its this case by
>>>             > null
>>>             > no methods
>>>             > no methods
>>>             > list == null
>>>             > List.of(...)
>>>             > get, size
>>>             > get, size
>>>             > instanceof FullyImmutable
>>>             > Collections.unmodifiableList(...)
>>>             > get, size
>>>             > get, size, add, set
>>>             > !(instanceof Addable) && !(instanceof Settable)
>>>             > Arrays.asList(...)
>>>             > get, size, set
>>>             > get, size, set
>>>             > instanceof Settable
>>>             > new ArrayList<>()
>>>             > get, size, add, set
>>>             > get, size, add, set
>>>             > instanceof Settable && instanceof Addable
>>>             > In the same way a RandomAccess check let's
>>>             implementations decide whether they want to try an
>>>             alternative algorithm or crash, some marker "capability"
>>>             interfaces would let users of a collection decide if
>>>             they want to clone what they are given before working on it.
>>>             >
>>>             >
>>>             > --------------
>>>             >
>>>             > So the applicability of this would be that the list
>>>             returned by List.of could implement FullyImmutable,
>>>             signifying that there is no caller which might have a
>>>             mutable handle on the collection. Then List.of could
>>>             check for this interface and skip a copy.
>>>             >
>>>             >
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220826/056df455/attachment-0001.htm>

From naoto at openjdk.org  Fri Aug 26 21:48:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 21:48:14 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Changed the paragraph to @implSpec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/d2608451..06cfc222

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

PR: https://git.openjdk.org/jdk/pull/9991

From duke at openjdk.org  Fri Aug 26 21:48:19 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 26 Aug 2022 21:48:19 GMT
Subject: RFR: JDK-8289949 Improve test coverage for XPath: operators [v2]
In-Reply-To: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
References: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
Message-ID: <33iS32Gt8_kcZBtyc9EQhW30SPZrBWOic1db6d2fmn8=.b72ade9c-2bee-4fd7-bd96-5c67923b90ff@github.com>

> Provided coverage for XPath operators. Operators include:
> * Boolean operators: or, and, =, !=, <, <=, >, >=
> * Number operators: +, -, *, div, mod
> * Union operator: |

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10047/files
  - new: https://git.openjdk.org/jdk/pull/10047/files/f593e71d..fb252477

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10047&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10047&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10047.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10047/head:pull/10047

PR: https://git.openjdk.org/jdk/pull/10047

From naoto at openjdk.org  Fri Aug 26 21:48:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 21:48:15 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
 <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>
Message-ID: <EK5-OSVqB_5OwiytXkuQaEWcb-Pxe9P2TuHFwREsopM=.c21800d3-6e8c-4b46-af12-2a82a38734d0@github.com>

On Fri, 26 Aug 2022 20:57:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting the fix to BreakIterator.isBoundary()
>
> src/java.base/share/classes/java/text/BreakIterator.java line 107:
> 
>> 105:  * <a href="https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries">
>> 106:  * Grapheme Cluster Boundaries</a> section in the Unicode Standard Annex #29.
>> 107:  *
> 
> I would say this is an `@implSpec` instead of an `@implNote` because we want applications to be able to rely on this behavior if they're using the default implementation. Also please make corresponding update to the CSR.

Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/9991

From bpb at openjdk.org  Fri Aug 26 22:20:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 22:20:24 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v9]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <peqHjRD2zqUTKxU_1raX0gwcT0FbgHFulMa85fBCFCc=.8eb4c1ee-dd5a-48d3-be94-c2993d9bc3da@github.com>

> 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.

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 16 additional commits since the last revision:

 - 6478546: Revert use of temporary direct buffers; move parameter checks to Java layer
 - Merge
 - 6478546: Eliminate a subtraction from RandomAccessFile.bufferSize()
 - Merge
 - 6478546: Miscellaneous cleanup
 - Merge
 - Merge
 - 6478546: Use dynamically sized temporary direct buffers
 - Merge
 - Merge
 - ... and 6 more: https://git.openjdk.org/jdk/compare/2f9d07c9...2532c0b3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8235/files
  - new: https://git.openjdk.org/jdk/pull/8235/files/9d7e4fbf..2532c0b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=07-08

  Stats: 58452 lines in 1100 files changed: 27738 ins; 25488 del; 5226 mod
  Patch: https://git.openjdk.org/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.org/jdk/pull/8235

From bpb at openjdk.org  Fri Aug 26 22:20:29 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 22:20:29 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v8]
In-Reply-To: <YMzDrRyHBqq2_DMtkH1p8MftKQKbw-3l3aXHxnDyAvI=.62d63506-8745-46ca-872e-2c8a8826b696@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <YMzDrRyHBqq2_DMtkH1p8MftKQKbw-3l3aXHxnDyAvI=.62d63506-8745-46ca-872e-2c8a8826b696@github.com>
Message-ID: <aJJZluclMpdzCmNkNG1qPCO5vuJc3n-kvDwGLj4L_rw=.77852c8f-4657-425f-b494-6d611d861216@github.com>

On Wed, 3 Aug 2022 17:14:13 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.
>
> 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 14 additional commits since the last revision:
> 
>  - 6478546: Eliminate a subtraction from RandomAccessFile.bufferSize()
>  - Merge
>  - 6478546: Miscellaneous cleanup
>  - Merge
>  - Merge
>  - 6478546: Use dynamically sized temporary direct buffers
>  - Merge
>  - Merge
>  - 6478546: Add break in write loop on ExceptionOccurred
>  - Merge
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/50a06466...9d7e4fbf

Using the temporary direct buffer cache to provide intermediate native memory is not a good solution as direct memory may be limited. Hence the patch is reverted to its prior state, modified to move parameter checking up to the Java layer, and simplified to keep `Blocker` use to within the `readBytes` and `writeBytes` methods. This patch uses less memory and has generally higher throughput than the master branch. Sample benchmark measurements on macOS are as follows:



   RandomAccessFile::read(byte[])

                   ops / sec
    length      master       patch
     16384  468119.718  501174.185
     32768  328305.094  353844.578
    262144   48575.747   52739.050
   1048576   13176.250   13723.486
  10485760     378.469     596.246
 251503002      10.554      20.784
 524288000       5.095      10.014
1000000000       1.743       5.254


   RandomAccessFile::write(byte[])

                   ops / sec
    length      master       patch
     16384  328584.712  353691.078
     32768  252836.010  276133.188
    262144   46072.526   38558.946
   1048576   12908.426    9716.200
  10485760     194.396     498.384
 251503002       7.649      18.175
 524288000       3.643       8.524
1000000000       1.202       4.491

-------------

PR: https://git.openjdk.org/jdk/pull/8235

From joehw at openjdk.org  Fri Aug 26 22:48:40 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 26 Aug 2022 22:48:40 GMT
Subject: RFR: JDK-8289949 Improve test coverage for XPath: operators [v2]
In-Reply-To: <33iS32Gt8_kcZBtyc9EQhW30SPZrBWOic1db6d2fmn8=.b72ade9c-2bee-4fd7-bd96-5c67923b90ff@github.com>
References: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
 <33iS32Gt8_kcZBtyc9EQhW30SPZrBWOic1db6d2fmn8=.b72ade9c-2bee-4fd7-bd96-5c67923b90ff@github.com>
Message-ID: <YR04iK_S3jKo2BkCVIdKeAMH4u9AT-wSBC3oGyV4n9k=.04523ad8-40f5-4731-93d8-c5e32d0943f8@github.com>

On Fri, 26 Aug 2022 21:48:19 GMT, Bill Huang <duke at openjdk.org> wrote:

>> Provided coverage for XPath operators. Operators include:
>> * Boolean operators: or, and, =, !=, <, <=, >, >=
>> * Number operators: +, -, *, div, mod
>> * Union operator: |
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Thanks for the update.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10047

From smarks at openjdk.org  Fri Aug 26 23:15:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 23:15:42 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Minor adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/783b3b59..9796557d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=05-06

  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

PR: https://git.openjdk.org/jdk/pull/9437

From naoto at openjdk.org  Sat Aug 27 00:24:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 27 Aug 2022 00:24:56 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows enviromnent [v3]
In-Reply-To: <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
Message-ID: <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>

On Fri, 26 Aug 2022 06:32:35 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows

LGTM

test/jdk/tools/launcher/I18NArgTest.java line 104:

> 102:         // we expect that system property value to be passed along to the main method with the
> 103:         // correct encoding
> 104:         // If <unicodestr> contains space or tab, it should beenclosed with double quotes.

Nit: space is missing between "be" and "enclosed"

test/jdk/tools/launcher/I18NArgTest.java line 147:

> 145:             for (int i = 0; i < sysPropVal.length(); i++) {
> 146:                 sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
> 147:             }

It's OK as it stands, but this loop could be replaced with a `HexFormat` one-liner.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9389

From naoto at openjdk.org  Sat Aug 27 00:28:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 27 Aug 2022 00:28:01 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows enviromnent [v3]
In-Reply-To: <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
Message-ID: <UioM9RYGAaexsAw9CbNlqnpJLTIac1OomGAqGsN_VyI=.c99eb251-314b-44b9-bf34-a83e7c9d4e2d@github.com>

On Fri, 26 Aug 2022 06:32:35 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows

BTW, please correct the PR title (contains a typo) which mismatches the JBS issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From jpai at openjdk.org  Sat Aug 27 06:06:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Aug 2022 06:06:49 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v4]
In-Reply-To: <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
Message-ID: <Et1MvcXBxjGh2-FleRCwuasBZazgFhyUHb0fKINuGkM=.ad7e178b-55d4-4b09-88f5-2db1df0f0960@github.com>

On Fri, 26 Aug 2022 15:06:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From alanb at openjdk.org  Sat Aug 27 06:56:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Aug 2022 06:56:10 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v5]
In-Reply-To: <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>
Message-ID: <T6Ux3_N-rXtcA9-sKMzEpRf9M_y262WB5Z_Ci97rE74=.1a60c120-f9f6-4b6d-bd68-af30c2fa186d@github.com>

On Fri, 26 Aug 2022 20:59:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = this.read();
>>     int ch2 = this.read();
>>     int ch3 = this.read();
>>     int ch4 = this.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>       throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> This can be improved by using bulk reads:
>> 
>> public final int readInt() throws IOException {
>>   readFully(readBuffer, 0, 4);
>>   return Bits.getInt(readBuffer, 0);
>> }
>> 
>> Benchmarking:
>> 
>> baselile
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
>> 
>> patch
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8292937: Fix error C2057
>  - 8292937: Remove unused method

src/java.base/share/native/libjava/io_util.c line 108:

> 106:                 ((*(buf + 6) & 0xFF) << 8) +
> 107:                 ((*(buf + 7) & 0xFF)));
> 108:     }

Doing this in a JNI method is problematic for several reasons and I think we should try to keep the JNI methods as simple/short as possible, ideally map to a single syscall and not do too much if possible. In the medium/long term then many of the native methods in this area will be replaced anyway, maybe by re-implementing RAF/etc. on NIO, maybe by replacing the JNI code with the java.lang.foreign APIs. In addition, I expect there will be another tranche of changes that will significantly change this code for virtual threads to allow the underlying thread be released when doing for file I/O.

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From alanb at openjdk.org  Sat Aug 27 08:21:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Aug 2022 08:21:56 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
Message-ID: <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>

On Fri, 26 Aug 2022 23:15:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor adjustments

src/java.base/share/classes/java/lang/Thread.java line 70:

> 68:  * The newly started thread invokes the task's {@link Runnable#run() run} method.
> 69:  *
> 70:  * <p> A platform thread <i>terminates</i> if either its {@code run} method completes

I don't think the update in 9796557d works. It switches to talking about the termination of platform threads before we've introduced what a platform thread is. It also switches to talking about the Thread.run method when the focus in the previous paragraph has been the the task that the thread executes. If we really need this here then the second paragraph will need to explain that it is also possible to extend Thread and override the run method.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From aturbanov at openjdk.org  Sun Aug 28 13:28:59 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 28 Aug 2022 13:28:59 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation
Message-ID: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>

Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

-------------

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in MergeCollation
 - [PATCH] Replace uses of StringBuffer with StringBuilder in MergeCollation

Changes: https://git.openjdk.org/jdk/pull/10007/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10007&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293008
  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10007/head:pull/10007

PR: https://git.openjdk.org/jdk/pull/10007

From aturbanov at openjdk.org  Sun Aug 28 13:31:07 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 28 Aug 2022 13:31:07 GMT
Subject: RFR: 8293009: Remove unused field 'millisPerHour' in DateFormatSymbols
Message-ID: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>

Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

-------------

Commit messages:
 - [PATCH] Unused field DateFormatSymbols.millisPerHour

Changes: https://git.openjdk.org/jdk/pull/10005/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10005&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293009
  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10005.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10005/head:pull/10005

PR: https://git.openjdk.org/jdk/pull/10005

From duke at openjdk.org  Sun Aug 28 17:01:21 2022
From: duke at openjdk.org (Bill Huang)
Date: Sun, 28 Aug 2022 17:01:21 GMT
Subject: Integrated: JDK-8289949 Improve test coverage for XPath: operators
In-Reply-To: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
References: <8u4koV__TxIc6KrcHYaPwnlGew0QDQ048yDeFUkW7BE=.4b373d5b-620c-4962-82c2-811a212748e2@github.com>
Message-ID: <TdM3yuBq3Mdyizg7rH7dJfDgiqrqzKFNHPwqgZkwLcc=.ea16f1e3-de88-4f9c-adfe-0d881a4a2067@github.com>

On Fri, 26 Aug 2022 16:48:03 GMT, Bill Huang <duke at openjdk.org> wrote:

> Provided coverage for XPath operators. Operators include:
> * Boolean operators: or, and, =, !=, <, <=, >, >=
> * Number operators: +, -, *, div, mod
> * Union operator: |

This pull request has now been integrated.

Changeset: f6b63601
Author:    Bill Huang <bill.w.huang at oracle.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6b636015573f9b88133efba2f87bed80f463a96
Stats:     141 lines in 1 file changed: 141 ins; 0 del; 0 mod

8289949: Improve test coverage for XPath: operators

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10047

From lbourges at openjdk.org  Sun Aug 28 19:09:17 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 28 Aug 2022 19:09:17 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v16]
In-Reply-To: <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
Message-ID: <-oZqaUjRE3y458d-LtIxy7w3WFnptPo9GAUHVClJ-UI=.30616385-c3cc-4238-a79f-d7a141d98d10@github.com>

On Tue, 2 Aug 2022 13:57:03 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)
>   
>   * Optimized and unified buffer allocation
>   * Minor comment changes

I am disappointed as Vladimir's OCA was cancelled as he is our sorting expert from Russia since jdk7 !
@AlanBateman @mbreinhold  should we close the PR and propose myself a new one, as vladimir agrees to go on ?

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From dholmes at openjdk.org  Sun Aug 28 22:24:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 28 Aug 2022 22:24:20 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
Message-ID: <pDe2-0ryMEZ1Gb6IhTOYzIKbDp-hQMjNg3y4U4ceQpk=.17c15f61-2169-4e20-b664-738882d21663@github.com>

On Fri, 26 Aug 2022 23:15:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor adjustments

src/java.base/share/classes/java/lang/Runtime.java line 65:

> 63:  * <p>In contrast to {@link #exit exit}, the {@link #halt halt} method does not initiate the
> 64:  * shutdown sequence. See the <a href="#termination">Java Virtual Machine Termination</a> section
> 65:  * below.

The forward ref seems inappropriate when this is the section describing which events trigger the shutdown sequence.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From dholmes at openjdk.org  Sun Aug 28 22:24:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 28 Aug 2022 22:24:22 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
 <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>
Message-ID: <oGzFPebmEl9Sww4TzDlySv-11G55f3RBlpEl-sg6HEc=.00521a1b-8e66-4f6d-8d74-3f5afdef0f6a@github.com>

On Sat, 27 Aug 2022 08:18:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor adjustments
>
> src/java.base/share/classes/java/lang/Thread.java line 70:
> 
>> 68:  * The newly started thread invokes the task's {@link Runnable#run() run} method.
>> 69:  *
>> 70:  * <p> A platform thread <i>terminates</i> if either its {@code run} method completes
> 
> I don't think the update in 9796557d works. It switches to talking about the termination of platform threads before we've introduced what a platform thread is. It also switches to talking about the Thread.run method when the focus in the previous paragraph has been the the task that the thread executes. If we really need this here then the second paragraph will need to explain that it is also possible to extend Thread and override the run method.

I don't think we need to distinguish between platform and virtual threads here at all. Isn't it the case that virtual threads also have a run() method and they too terminate when run() completes as described (together with UEH)? The fact most Thread run() methods call something else's run() method is immaterial. We don't know what a run() method will do, but whatever it is once it completes then the thread has terminated.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From shade at openjdk.org  Mon Aug 29 06:00:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 06:00:28 GMT
Subject: RFR: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks [v4]
In-Reply-To: <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
 <f2zWY1cN8rogiOkfLJd3tB_3Suf6cb91L0KVu9NOzGI=.ce334d21-d518-4780-9b2d-670bf87c8de1@github.com>
Message-ID: <wj_By541fTBSd6nHv2zwRXuQZZv1Ryje2jAkXHsJwR8=.dbc4567b-49b5-4a27-8b87-3a072e5759bb@github.com>

On Fri, 26 Aug 2022 15:06:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Look at implementation and figure out what happens if you do:
>> 
>> 
>>  computeHash("SHA-1") = someHash;
>>  computeHash("SHA-256") = ...?
>> 
>> 
>> The caching method should actually check the algorithms match.
>> 
>> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 release, `java/lang/module` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments

Thank you all.

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From shade at openjdk.org  Mon Aug 29 06:01:42 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 06:01:42 GMT
Subject: Integrated: 8292983: ModuleReferenceImpl.computeHash should record
 algorithm for cache checks
In-Reply-To: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
References: <6yFWNcATKeS2Oz4Te_fzimilzhKaXxZvexrlSeoyC2g=.ec27f71f-9f72-4ba4-8c4f-2824c5b55429@github.com>
Message-ID: <y4V990OtYi9HwZKOXWGnidVw8eNEgf8XOXrAWq8CV3o=.4f9b31fe-1534-4ea9-9c65-b5b4e0bf0de6@github.com>

On Fri, 26 Aug 2022 13:55:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Look at implementation and figure out what happens if you do:
> 
> 
>  computeHash("SHA-1") = someHash;
>  computeHash("SHA-256") = ...?
> 
> 
> The caching method should actually check the algorithms match.
> 
> Not a bug at this point, since only use SHA-256 today, but this is a landmine ready to fire. 
> 
> Additional testing:
>  - [x] Linux x86_64 release, `java/lang/module` tests

This pull request has now been integrated.

Changeset: a476ec5c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a476ec5c81968e9a8cf7fb02f61cc4a5c8c2d520
Stats:     16 lines in 1 file changed: 7 ins; 0 del; 9 mod

8292983: ModuleReferenceImpl.computeHash should record algorithm for cache checks

Reviewed-by: alanb, mchung, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10044

From duke at openjdk.org  Mon Aug 29 07:21:59 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Aug 2022 07:21:59 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v5]
In-Reply-To: <T6Ux3_N-rXtcA9-sKMzEpRf9M_y262WB5Z_Ci97rE74=.1a60c120-f9f6-4b6d-bd68-af30c2fa186d@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>
 <T6Ux3_N-rXtcA9-sKMzEpRf9M_y262WB5Z_Ci97rE74=.1a60c120-f9f6-4b6d-bd68-af30c2fa186d@github.com>
Message-ID: <35kHPqughIcO5i3FdQBjWTlspWawD_zFiBxeydUJ73c=.a09205a7-dc22-480d-958b-bb5b89415396@github.com>

On Sat, 27 Aug 2022 06:52:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8292937: Fix error C2057
>>  - 8292937: Remove unused method
>
> src/java.base/share/native/libjava/io_util.c line 108:
> 
>> 106:                 ((*(buf + 6) & 0xFF) << 8) +
>> 107:                 ((*(buf + 7) & 0xFF)));
>> 108:     }
> 
> Doing this in a JNI method is problematic for several reasons and I think we should try to keep the JNI methods as simple/short as possible, ideally map to a single syscall and not do too much if possible. In the medium/long term then many of the native methods in this area will be replaced anyway, maybe by re-implementing RAF/etc. on NIO, maybe by replacing the JNI code with the java.lang.foreign APIs. In addition, I expect there will be another tranche of changes that will significantly change this code for virtual threads to allow the underlying thread be released when doing for file I/O.

So I should roll the changes to VM back and modify only Java code, right?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From alanb at openjdk.org  Mon Aug 29 08:23:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Aug 2022 08:23:27 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <oGzFPebmEl9Sww4TzDlySv-11G55f3RBlpEl-sg6HEc=.00521a1b-8e66-4f6d-8d74-3f5afdef0f6a@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
 <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>
 <oGzFPebmEl9Sww4TzDlySv-11G55f3RBlpEl-sg6HEc=.00521a1b-8e66-4f6d-8d74-3f5afdef0f6a@github.com>
Message-ID: <5dksriRuuZ4zEr_XQTk9zVcJ2Y77KoX9POg8H40IMtI=.b5e1ea74-dfb0-413a-b731-47f7d7106351@github.com>

On Sun, 28 Aug 2022 22:20:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 70:
>> 
>>> 68:  * The newly started thread invokes the task's {@link Runnable#run() run} method.
>>> 69:  *
>>> 70:  * <p> A platform thread <i>terminates</i> if either its {@code run} method completes
>> 
>> I don't think the update in 9796557d works. It switches to talking about the termination of platform threads before we've introduced what a platform thread is. It also switches to talking about the Thread.run method when the focus in the previous paragraph has been the the task that the thread executes. If we really need this here then the second paragraph will need to explain that it is also possible to extend Thread and override the run method.
>
> I don't think we need to distinguish between platform and virtual threads here at all. Isn't it the case that virtual threads also have a run() method and they too terminate when run() completes as described (together with UEH)? The fact most Thread run() methods call something else's run() method is immaterial. We don't know what a run() method will do, but whatever it is once it completes then the thread has terminated.

There are subtle differences (invoking a virtual Thread's run method directly does no nothing) but that is too much detail and would confusing to say anything about in the introduction paragraphs.

The following is closer to what I think we should have. The existing paragraph 2 describes starting a thread so this is where the Thread.run method is introduced. Paragraph 3 follows to describe termination.


 * <p> {@code Thread} defines constructors and a {@link Builder} to create threads.
 * {@linkplain #start() Starting} a thread schedules the newly started thread to execute
 * its {@link #run() run} method. The thread executes concurrently with the thread that
 * caused it to start.
 *
 * <p> A thread <i>terminates</i> if either its {@code run} method completes normally,
 * or if its {@code run} method completes abruptly and the appropriate {@linkplain
 * Thread.UncaughtExceptionHandler uncaught exception handler} completes normally or
 * abruptly. With no code left to run, the thread has completed execution. Thread
 * defines the {@link #join() join} method to wait for a thread to terminate.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From duke at openjdk.org  Mon Aug 29 08:46:20 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Aug 2022 08:46:20 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

?????? ??????? 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:

 - 8292698: Reuse existing code
 - Merge branch 'master' into 8292698
 - 8292698: Fix copyright year
 - 8292698: Revert dubious changes
 - 8292698: Improve performance of reading from DataInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9956/files
  - new: https://git.openjdk.org/jdk/pull/9956/files/1535e925..3ea66641

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9956&range=02-03

  Stats: 19974 lines in 555 files changed: 7702 ins; 9267 del; 3005 mod
  Patch: https://git.openjdk.org/jdk/pull/9956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9956/head:pull/9956

PR: https://git.openjdk.org/jdk/pull/9956

From shade at openjdk.org  Mon Aug 29 09:03:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 09:03:28 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
Message-ID: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>

`jmod`/`jlink` are executed during build time to produce the `jmod` and the base modules image. On slow hardware (Raspberry Pi -class, for example) and/or slow VMs (debug, interpreter-only, for example) this takes a while. Profiling shows the considerable time is spent on hashing modules either for writing out the ModuleHash attribute or for verifying the hashes are good.

Those paths can be parallelized to make them quite faster.

The major contributors to module hashing are `java.base`, `jdk.desktop` and `jdk.localedata`, so we have a significant opportunity for parallelism here. 

Motivational improvements on `make clean-images images`:


# x86_64 Server, release

# Baseline
real	0m11.895s
user	1m4.526s
sys	0m10.715s

# Patched
real	0m10.701s   ; <--- 1.1x improvement
user	1m5.097s
sys	0m11.260s

# x86_64 Zero, release

# Baseline
real	5m20.335s
user	7m7.791s
sys	0m7.258s

# Patched
real	2m23.551s  ; <--- 2.23x improvement
user	7m14.442s
sys	0m7.856s


Additional testing: 
  - [x] Linux x86_64 fastdebug, `java/util/jar`
  - [x] Linux x86_64 fastdebug, `tools/jmod`
  - [x] Linux x86_64 fastdebug, `tools/jlink`
  - [x] Linux x86_64 fastdebug `tier1`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10060/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10060&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293017
  Stats: 60 lines in 2 files changed: 40 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10060.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10060/head:pull/10060

PR: https://git.openjdk.org/jdk/pull/10060

From alanb at openjdk.org  Mon Aug 29 09:22:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Aug 2022 09:22:09 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
In-Reply-To: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
Message-ID: <uNygC4NIk1UnwGeEhTkCkJmBYJgrSirDvpfN095KRQE=.7ae81fce-088b-4f41-ae07-f3e8d6556333@github.com>

On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `jmod`/`jlink` are executed during build time to produce the `jmod` and the base modules image. On slow hardware (Raspberry Pi -class, for example) and/or slow VMs (debug, interpreter-only, for example) this takes a while. Profiling shows the considerable time is spent on hashing modules either for writing out the ModuleHash attribute or for verifying the hashes are good.
> 
> Those paths can be parallelized to make them quite faster.
> 
> The major contributors to module hashing are `java.base`, `jdk.desktop` and `jdk.localedata`, so we have a significant opportunity for parallelism here. 
> 
> Motivational improvements on `make clean-images images`:
> 
> 
> # x86_64 Server, release
> 
> # Baseline
> real	0m11.895s
> user	1m4.526s
> sys	0m10.715s
> 
> # Patched
> real	0m10.701s   ; <--- 1.1x improvement
> user	1m5.097s
> sys	0m11.260s
> 
> # x86_64 Zero, release
> 
> # Baseline
> real	5m20.335s
> user	7m7.791s
> sys	0m7.258s
> 
> # Patched
> real	2m23.551s  ; <--- 2.23x improvement
> user	7m14.442s
> sys	0m7.856s
> 
> 
> Additional testing: 
>   - [x] Linux x86_64 fastdebug, `java/util/jar`
>   - [x] Linux x86_64 fastdebug, `tools/jmod`
>   - [x] Linux x86_64 fastdebug, `tools/jlink`
>   - [x] Linux x86_64 fastdebug `tier1`

This issue will require discussion as it potentially impacts usage at run-time when the resolver runs at startup or when creating module layers. I also wonder if it has an impact on JDK builds where many jobs are running jmod at the same time. It may be that this has to be configured by a system property so that it can be enabled only in the JDK build.

Also just to say that Claes removed all the lambda expressions from this code in JDK 9 to help with startup as that will have to checking too. Also if we are changing this code then we should try to keep the style/conventions/line-lengths consistent where possible.

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From duke at openjdk.org  Mon Aug 29 09:37:19 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Aug 2022 09:37:19 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
In-Reply-To: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
Message-ID: <JcL_oj0aoFdnG4KlY-0ZA-NMOaMRsyiGyeQiESznlG4=.336cd92f-f849-428f-85be-547fbba3965b@github.com>

On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `jmod`/`jlink` are executed during build time to produce the `jmod` and the base modules image. On slow hardware (Raspberry Pi -class, for example) and/or slow VMs (debug, interpreter-only, for example) this takes a while. Profiling shows the considerable time is spent on hashing modules either for writing out the ModuleHash attribute or for verifying the hashes are good.
> 
> Those paths can be parallelized to make them quite faster.
> 
> The major contributors to module hashing are `java.base`, `jdk.desktop` and `jdk.localedata`, so we have a significant opportunity for parallelism here. 
> 
> Motivational improvements on `make clean-images images`:
> 
> 
> # x86_64 Server, release
> 
> # Baseline
> real	0m11.895s
> user	1m4.526s
> sys	0m10.715s
> 
> # Patched
> real	0m10.701s   ; <--- 1.1x improvement
> user	1m5.097s
> sys	0m11.260s
> 
> # x86_64 Zero, release
> 
> # Baseline
> real	5m20.335s
> user	7m7.791s
> sys	0m7.258s
> 
> # Patched
> real	2m23.551s  ; <--- 2.23x improvement
> user	7m14.442s
> sys	0m7.856s
> 
> 
> Additional testing: 
>   - [x] Linux x86_64 fastdebug, `java/util/jar`
>   - [x] Linux x86_64 fastdebug, `tools/jmod`
>   - [x] Linux x86_64 fastdebug, `tools/jlink`
>   - [x] Linux x86_64 fastdebug `tier1`

src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 170:

> 168:     static ModuleHashes generate(Set<ModuleReference> mrefs, String algorithm) {
> 169:         Map<String, byte[]> nameToHash = new ConcurrentHashMap<>();
> 170:         mrefs.stream().parallel().forEach(mref -> {

[AFAIK](https://stackoverflow.com/questions/28985704/parallel-stream-from-a-hashset-doesnt-run-in-parallel) streams taken from HashSet might have weak parallelism, so maybe it's worth wrapping `mrefs` into an ArrayList?

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From shade at openjdk.org  Mon Aug 29 10:41:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 10:41:13 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
 [v2]
In-Reply-To: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
Message-ID: <r-o9tUFnyjYbWLjCiBr1iqi-1FEdA-NImUSgJFwQSck=.be49616e-dea5-4b0c-b815-02d7c54553a3@github.com>

> `jmod`/`jlink` are executed during build time to produce the `jmod` and the base modules image. On slow hardware (Raspberry Pi -class, for example) and/or slow VMs (debug, interpreter-only, for example) this takes a while. Profiling shows the considerable time is spent on hashing modules either for writing out the ModuleHash attribute or for verifying the hashes are good.
> 
> Those paths can be parallelized to make them quite faster.
> 
> The major contributors to module hashing are `java.base`, `jdk.desktop` and `jdk.localedata`, so we have a significant opportunity for parallelism here. 
> 
> Motivational improvements on `make clean-images images`:
> 
> 
> # x86_64 Server, release
> 
> # Baseline
> real	0m11.895s
> user	1m4.526s
> sys	0m10.715s
> 
> # Patched
> real	0m10.701s   ; <--- 1.1x improvement
> user	1m5.097s
> sys	0m11.260s
> 
> # x86_64 Zero, release
> 
> # Baseline
> real	5m20.335s
> user	7m7.791s
> sys	0m7.258s
> 
> # Patched
> real	2m23.551s  ; <--- 2.23x improvement
> user	7m14.442s
> sys	0m7.856s
> 
> 
> Additional testing: 
>   - [x] Linux x86_64 fastdebug, `java/util/jar`
>   - [x] Linux x86_64 fastdebug, `tools/jmod`
>   - [x] Linux x86_64 fastdebug, `tools/jlink`
>   - [x] Linux x86_64 fastdebug `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Touchups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10060/files
  - new: https://git.openjdk.org/jdk/pull/10060/files/877ff17d..2389fdfd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10060&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10060&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10060.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10060/head:pull/10060

PR: https://git.openjdk.org/jdk/pull/10060

From shade at openjdk.org  Mon Aug 29 10:54:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 10:54:08 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
In-Reply-To: <uNygC4NIk1UnwGeEhTkCkJmBYJgrSirDvpfN095KRQE=.7ae81fce-088b-4f41-ae07-f3e8d6556333@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
 <uNygC4NIk1UnwGeEhTkCkJmBYJgrSirDvpfN095KRQE=.7ae81fce-088b-4f41-ae07-f3e8d6556333@github.com>
Message-ID: <XZqIPQrQaiTfKQeET46IxH_Ozp2qyRYmrz-6AJmKawQ=.e0849464-7192-4316-bf7a-5983b6e3a1a8@github.com>

On Mon, 29 Aug 2022 09:18:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This issue will require discussion as it potentially impacts usage at run-time when the resolver runs at startup or when creating module layers. 

Startup with/without CDS:


$ perf stat -r 100 build/linux-x86_64-server-release/images/jdk/bin/java Hello

# Baseline
 With CDS: 0.0323543 +- 0.0000789 seconds time elapsed  ( +-  0.24% )
 Without CDS: 0.071471 +- 0.000500 seconds time elapsed  ( +-  0.70% )

# Patched
 With CDS: 0.0328651 +- 0.0000780 seconds time elapsed  ( +-  0.24% )
 Without CDS:  0.072745 +- 0.000472 seconds time elapsed  ( +-  0.65% )


So there seem to be some minor impact, but nothing drastic. I would be very surprised if we actually verified the module hashes at startup! That would take minutes to startup on Zero, as observed by its build-time checking. And we don't see that, apparently.

> I also wonder if it has an impact on JDK builds where many jobs are running jmod at the same time. It may be that this has to be configured by a system property so that it can be enabled only in the JDK build.

The normal build already runs a lot of `jmod`-s at once. But that would not help when you have the fat `jmod java.base` at the end of the build, where no external parallelism exists. At that point, internal `Resolver` parallelism helps a lot.

> Also just to say that Claes removed all the lambda expressions from this code in JDK 9 to help with startup as that will have to checking too. Also if we are changing this code then we should try to keep the style/conventions/line-lengths consistent where possible.

I reverted some brace changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From alanb at openjdk.org  Mon Aug 29 11:11:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Aug 2022 11:11:12 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
In-Reply-To: <XZqIPQrQaiTfKQeET46IxH_Ozp2qyRYmrz-6AJmKawQ=.e0849464-7192-4316-bf7a-5983b6e3a1a8@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
 <uNygC4NIk1UnwGeEhTkCkJmBYJgrSirDvpfN095KRQE=.7ae81fce-088b-4f41-ae07-f3e8d6556333@github.com>
 <XZqIPQrQaiTfKQeET46IxH_Ozp2qyRYmrz-6AJmKawQ=.e0849464-7192-4316-bf7a-5983b6e3a1a8@github.com>
Message-ID: <JPTVbbuZaaBDmVF_B1tPqLRrf-TZLatNd_mjlQNGTbM=.f2fba175-571c-46c0-b1b5-1020dd7864f4@github.com>

On Mon, 29 Aug 2022 10:50:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I would be very surprised if we actually verified the module hashes at startup! That would take minutes to startup on Zero, as observed by its build-time checking. And we don't see that, apparently.

Module hashes are checked at startup when deploying with tightly coupled modules on the module path. You should see some examples if you run the tests test/jdk/tools/jmod/hashes. It's the same thing when configuring the Configuration for module layers at run-time. In the JDK build, the hashes are added at packaging time so you don't see checking when using exploded builds. At run-time, without an application module, then modules are loaded from the run-time image where we can safety skip the checking.

I have no objection to using a parallel-stream be opt-in by the JDK build but I don't think it can be default because it impacts the behavior of standard APIs and out-of-the-box behavior.

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From simonis at openjdk.org  Mon Aug 29 11:58:15 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 29 Aug 2022 11:58:15 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Updated JavaDoc according to @mbreinhold's suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7986/files
  - new: https://git.openjdk.org/jdk/pull/7986/files/62e25d42..d82c7526

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=10-11

  Stats: 56 lines in 7 files changed: 12 ins; 1 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.org/jdk/pull/7986

From shade at openjdk.org  Mon Aug 29 12:15:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 12:15:18 GMT
Subject: RFR: 8293017: Improve hash calculation parallelism in jmod/jlink
 [v2]
In-Reply-To: <JcL_oj0aoFdnG4KlY-0ZA-NMOaMRsyiGyeQiESznlG4=.336cd92f-f849-428f-85be-547fbba3965b@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
 <JcL_oj0aoFdnG4KlY-0ZA-NMOaMRsyiGyeQiESznlG4=.336cd92f-f849-428f-85be-547fbba3965b@github.com>
Message-ID: <hFhyCbaJKBmmceKKSsjQspT-aF6yM6jQ6OKTeYCZXN4=.1beed145-9252-41a1-b83e-5d3b8a5a46d8@github.com>

On Mon, 29 Aug 2022 09:33:44 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 170:
> 
>> 168:     static ModuleHashes generate(Set<ModuleReference> mrefs, String algorithm) {
>> 169:         Map<String, byte[]> nameToHash = new ConcurrentHashMap<>();
>> 170:         mrefs.stream().parallel().forEach(mref -> {
> 
> [AFAIK](https://stackoverflow.com/questions/28985704/parallel-stream-from-a-hashset-doesnt-run-in-parallel) streams taken from HashSet might have weak parallelism, so maybe it's worth wrapping `mrefs` into an ArrayList?

I instrumented the parallel tasks, and confirmed the full parallelism is used. So this is not an issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From duke at openjdk.org  Mon Aug 29 13:49:52 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 29 Aug 2022 13:49:52 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>

> Add support for named groups to java.util.regex.MatchResult

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8065554: MatchResult should provide values of named-capturing groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/c4282fe4..e7e29553

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=02-03

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From jolyjdia at gmail.com  Wed Aug 24 22:46:42 2022
From: jolyjdia at gmail.com (Zelva Lia)
Date: Thu, 25 Aug 2022 01:46:42 +0300
Subject: CopyOnWriteArrayList Collection.shuffle
In-Reply-To: <SJ0PR18MB4881A2DEEF99885BCB06190B83739@SJ0PR18MB4881.namprd18.prod.outlook.com>
References: <CAMETwp7LCVBLxfo25r7aqQ_X8vXjOOf5t=u5uG5X9EJ0a9O+cA@mail.gmail.com>
 <SJ0PR18MB4881A2DEEF99885BCB06190B83739@SJ0PR18MB4881.namprd18.prod.outlook.com>
Message-ID: <CAMETwp6iUuQR0V3DxRo+i7tL8A+1iL0C-ni4VPk5UmiEwWAqvQ@mail.gmail.com>

Well, yes, this is a solvable problem, albeit with additional copying, but
solvable, which cannot be said about other operations (for example, swap),
I lead to the fact that there are few specialized methods in COW that can
work inside synchronization and cannot be synchronized with by the
COWArrayList object itself, because it is synchronized with its private lock

??, 24 ???. 2022 ?. ? 23:26, Jason Mehrens <jason_mehrens at hotmail.com>:

> CopyOnWriteArrayList implements an efficient List::replaceAll so you could
> do something like:
>
> ====
> public static void main(String[] args) {
>         List<String> cowl = new CopyOnWriteArrayList<>(new
> String[]{"1","2","3"});
>         List<String> copy = Arrays.asList(cowl.toArray(new String[0]));
>         Collections.shuffle(copy);
>         Iterator<String> it = copy.iterator();
>         try {
>                 cowl.replaceAll(e -> it.next());
>         } catch (NoSuchElementException nsee) {
>                 throw new ConcurrentModificationException();
>         }
>
>         if (it.hasNext()) {
>                 throw new ConcurrentModificationException();
>         }
>
>         System.out.println(cowl);
> }
> ====
>
> Some of the non-random access branches in Collections.java could be
> updated to use List::replaceAll over ListIterator next/set.  Once
> Collections.java was using List::replaceAll you could then just wrap
> CopyOnWriteArrayList in a non-random access list.
>
> Jason
>
> ________________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Zelva
> Lia <jolyjdia at gmail.com>
> Sent: Friday, August 19, 2022 5:49 AM
> To: core-libs-dev at openjdk.org
> Subject: CopyOnWriteArrayList Collection.shuffle
>
> Hello, when shuffling the CopyOnWrite list with the standard
> Collections.shuffle method, performance anomalies occur, due to the fact
> that it calls the set method, which copies the array each time, a possible
> solution (crutch) is a random comparator for sorting, so sorting in COW is
> redefined to its own sub - blocking implementation
>
> Another problem with Collections.shuffle is that it's not exactly thread
> safe because it calls the size() method; and then iterates from it, also
> COW does not support modification inside the iterator (works on snapshots)
>
>
> COWCollectionsShuffle      0,008 ops/ms
> COWListRandomSort         1,089 ops/ms
> syncListCollectionsShuffle  0,950 ops/ms
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220825/b6b7ce5d/attachment.htm>

From rriggs at openjdk.org  Mon Aug 29 15:11:07 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Aug 2022 15:11:07 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <GVVK3Tj_cK5NHEyzCEz3XePjHGW_lDNyv4QFgNTb0mg=.a78167c9-6d07-4af5-9f66-4b2066c31984@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10007

From naoto at openjdk.org  Mon Aug 29 16:26:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 16:26:06 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <aaY57G2PyolHTe5dVq4KW-VxL6mBtwzBxvxZQiJp2-E=.35662b31-612f-493b-929f-0563317236ab@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

+1

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10007

From naoto at openjdk.org  Mon Aug 29 16:41:11 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 16:41:11 GMT
Subject: RFR: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <tHA8U4garyoiuBMtIU_f8Sl4fH03a_oMzUlKPR6X_QA=.cc0165f1-68d2-44fd-953f-193ed5c40f29@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

This looks good too.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10005

From bpb at openjdk.org  Mon Aug 29 16:49:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 29 Aug 2022 16:49:16 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <zQusT2LbybrbZ36KOE1z4j9ueiwti1WA0HNUO2XRucI=.49b8d943-28ef-4926-a9a0-e093b9ebc492@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From dfuchs at openjdk.org  Mon Aug 29 17:17:44 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 29 Aug 2022 17:17:44 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
In-Reply-To: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
Message-ID: <z6zhh7YPh9RTbOf4BPbkMIHGMCqwSajrk4B5Ms4QmSg=.23bd864a-4cc4-4207-a53b-2d4d1afa8942@github.com>

On Fri, 26 Aug 2022 19:09:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
> The extensively relies on references processing and invokes GC on a very short cycle.
> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
> 
> The delay between gc requests is extended to 200ms and the tests pass reliably.
> There are small improvements in diagnostic messages and cleanup of unused imports.

test/jdk/java/lang/ref/CleanerTest.java line 569:

> 567:         obj = null;
> 568:         checkCleaned(s.getSemaphore(), true,
> 569:                 "Object was cleaned using CleanerFactory.cleaner():");

So the message in case of failure for this case will now be?

Should have been run: Object was cleaned using CleanerFactory.cleaner():

-------------

PR: https://git.openjdk.org/jdk/pull/10048

From rriggs at openjdk.org  Mon Aug 29 18:35:06 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Aug 2022 18:35:06 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
In-Reply-To: <z6zhh7YPh9RTbOf4BPbkMIHGMCqwSajrk4B5Ms4QmSg=.23bd864a-4cc4-4207-a53b-2d4d1afa8942@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
 <z6zhh7YPh9RTbOf4BPbkMIHGMCqwSajrk4B5Ms4QmSg=.23bd864a-4cc4-4207-a53b-2d4d1afa8942@github.com>
Message-ID: <ExpBKJeIC83G5MJCHgvseDG4vr7qeLjyuc_wh5lUrHE=.214f477a-7eeb-45a1-9855-666e7906da9c@github.com>

On Mon, 29 Aug 2022 17:14:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
>> The extensively relies on references processing and invokes GC on a very short cycle.
>> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
>> 
>> The delay between gc requests is extended to 200ms and the tests pass reliably.
>> There are small improvements in diagnostic messages and cleanup of unused imports.
>
> test/jdk/java/lang/ref/CleanerTest.java line 569:
> 
>> 567:         obj = null;
>> 568:         checkCleaned(s.getSemaphore(), true,
>> 569:                 "Object was cleaned using CleanerFactory.cleaner():");
> 
> So the message in case of failure for this case will now be?
> 
> Should have been run: Object was cleaned using CleanerFactory.cleaner():

Yes, (just a typo fix); but the message describes the function of the cleanup
and is prefixed in the error as to whether it was run or not.

-------------

PR: https://git.openjdk.org/jdk/pull/10048

From mr at openjdk.org  Mon Aug 29 20:30:18 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Mon, 29 Aug 2022 20:30:18 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
Message-ID: <R3ZLdlQ-ci9LoajlkL8iuqS0VZBSg1wbbW-o0rUC3qQ=.25c55786-728c-4e3c-8656-05b6c8ea6289@github.com>

On Mon, 29 Aug 2022 11:58:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JavaDoc according to @mbreinhold's suggestions

Marked as reviewed by mr (Lead).

-------------

PR: https://git.openjdk.org/jdk/pull/7986

From naoto at openjdk.org  Mon Aug 29 21:41:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 21:41:20 GMT
Subject: Withdrawn: 8289227: Support for BCP 47 Extension T - Transformed
 Content
In-Reply-To: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
Message-ID: <73N1yjCvoMAXDZtFx04iOz09jCXxuKoNlNDpby8uxl0=.0e2867b9-3e58-4f32-a1b9-34f8e3997712@github.com>

On Fri, 22 Jul 2022 21:53:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9620

From darcy at openjdk.org  Tue Aug 30 00:12:33 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 00:12:33 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in
 javac
Message-ID: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>

Update to remove support for -source/-target/--release 7 from javac.

As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

-------------

Commit messages:
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - Test fixes.
 - Clean langtools test run.
 - CheckExamples passes.
 - Type annotations.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/76ee5495...f3095350

Changes: https://git.openjdk.org/jdk/pull/10074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8173605
  Stats: 4514 lines in 156 files changed: 25 ins; 4362 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

PR: https://git.openjdk.org/jdk/pull/10074

From darcy at openjdk.org  Tue Aug 30 00:20:09 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 00:20:09 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

Please also review the accompanying CSR:

https://bugs.openjdk.org/browse/JDK-8293047

Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed.

Tier 1 and tier 2 test results were clean with this changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From darcy at openjdk.org  Tue Aug 30 01:05:23 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 01:05:23 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <J2LDFqwlrsQBl2SWnpEOGHYpoA7T_Yj4EMhXEUBgnxg=.8181060a-e72b-4cf9-872f-db022962d948@github.com>
Message-ID: <7caOzUK-O_rtHE24lEnLDODLPj_gvixrSSFI-Is5zS0=.78f37a82-868c-4719-9145-cb2bd8df0588@github.com>

On Tue, 30 Aug 2022 00:16:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please also review the accompanying CSR:
> 
> https://bugs.openjdk.org/browse/JDK-8293047
> 
> Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed.
> 
> Tier 1 and tier 2 test results were clean with this changes.

PS I'll run a copyright update script before any push.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From alanb at openjdk.org  Tue Aug 30 06:29:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Aug 2022 06:29:52 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28:

> 26:  * @bug 8009267
> 27:  * @summary Verify uses of isAnnotationPresent compile under older source versions
> 28:  * @compile OldenCompilingWithDefaults.java

I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From jpai at openjdk.org  Tue Aug 30 08:56:18 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 08:56:18 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
In-Reply-To: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
Message-ID: <4c6QaBGRRuFva7pmEP4WxRcGUovywDnrz_g5F0_TLbY=.dce470a0-687f-4568-a23f-cb027171cdd3@github.com>

On Fri, 26 Aug 2022 19:09:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
> The extensively relies on references processing and invokes GC on a very short cycle.
> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
> 
> The delay between gc requests is extended to 200ms and the tests pass reliably.
> There are small improvements in diagnostic messages and cleanup of unused imports.

Hello Roger,

The change related to increasing the time to 200ms looks fine to me and even the typo fix. 

The prefix to the error message isn't too clear to me. Is the "Should (not) have been run" prefix implying that the "Cleaner should (not) have been run"?

While in this test, do you think we should change it to use `@enablePreview` instead of the `--enable-preview` options to the test definition section?

-------------

PR: https://git.openjdk.org/jdk/pull/10048

From jpai at openjdk.org  Tue Aug 30 09:02:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:02:00 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

src/java.base/share/classes/java/text/PatternEntry.java line 55:

> 53:      * Gets the current extension, quoted
> 54:      */
> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {

Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From jpai at openjdk.org  Tue Aug 30 09:04:12 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:04:12 GMT
Subject: RFR: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <vY_BUsk7ZsGe4ZMtRpJ_gUjV6i3con5CfdZq0xiR9hk=.ea8da569-04e6-4748-baa1-6a0d0050479b@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10005

From jpai at openjdk.org  Tue Aug 30 09:16:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:16:16 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)?

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From cstein at openjdk.org  Tue Aug 30 09:33:05 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 30 Aug 2022 09:33:05 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
 <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com>
Message-ID: <6A9Z9oXjfXGmi9_LWIF_TMtJtS483A98QA0rJPuzus0=.ab5a3a72-7877-4bbf-8c39-5663476ac5e1@github.com>

On Tue, 30 Aug 2022 09:14:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)?

Yes. Some systems require the exact version tag `7+1` others only the short version string `7`.

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From jpai at openjdk.org  Tue Aug 30 09:36:15 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:36:15 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5]
In-Reply-To: <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <H4D7dYDCNkNT__h1rsG31IVPAAnd4CHn6GAocTGIh2s=.28d25d85-34d9-4745-8369-17d31c39d213@github.com>
Message-ID: <RQ9Vo_kj5eYgQQAoKI7l7tJVurWIydpC_Bn4VyyVqY4=.3f8fe78e-b4f7-4853-ba51-9654a8477686@github.com>

On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9393

From duke at openjdk.org  Tue Aug 30 11:16:11 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Tue, 30 Aug 2022 11:16:11 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
Message-ID: <geIMTourVM2JPDotJdmMmHqoWnq5RnfToXq3KzrOdgM=.945c3d07-08a6-4143-8fbe-249845ad4eeb@github.com>

On Mon, 29 Aug 2022 13:49:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

If the most recent commit is OK in terms of Javadoc, I'll update the CSR accordingly

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From shade at openjdk.org  Tue Aug 30 14:18:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Aug 2022 14:18:11 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v7]
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Rewind back to 100 attempts, 1ms delay
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Pull Handles.get out of the weak retry loop
 - Drop weakDelay to 1
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Rework timeouts
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
 - Update copyrights
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b3450e93...fd6aa17b

-------------

Changes: https://git.openjdk.org/jdk/pull/9889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9889&range=06
  Stats: 951 lines in 45 files changed: 800 ins; 0 del; 151 mod
  Patch: https://git.openjdk.org/jdk/pull/9889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9889/head:pull/9889

PR: https://git.openjdk.org/jdk/pull/9889

From shade at openjdk.org  Tue Aug 30 14:25:56 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Aug 2022 14:25:56 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v7]
In-Reply-To: <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
Message-ID: <gQZG4pAGsxMF24r8fvgvGTO5wPWtHzsTYZnxXd0RHv4=.bf1d6416-ddf5-4ad5-921d-9503e6d94782@github.com>

On Tue, 30 Aug 2022 14:18:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Rewind back to 100 attempts, 1ms delay
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Pull Handles.get out of the weak retry loop
>  - Drop weakDelay to 1
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b3450e93...fd6aa17b

So, I have been playing with HiFive Unmatched board, and I can see that even in the single-threaded mode there weak CASes can spuriously fail when JIT compiler threads are very active at the same time. I suspect L1-tagging LR/SC fails just because we context-switch out a lot. 

On HiFive Unmatched, without any delay, it is common to see the long-tailed attempt counts that exceed 200 attempts. Adding the 1ms delay drops that long tail to fit under 10 attempts; I suspect because it provides a natural backoff on over-subscribed system, as thread would return back later if no resources are currently available. Still, that does not seem to hold when the rest of the system is running other parallel tests. Running `java/lang/invoke/VarHandles` with 50 attempts and 1ms delay still ocassionally fails the weak CAS tests. 

Running with 100 attempts and 1ms delay seems to pass it well (tried several times) -- which is what current version does. I think this is as good as it gets for a default mode. I also ran other platform tests, and there spurious failures are either not observed at all (x86 and friends), or we have 1..2 retries very rarely (for example, on AArch64 without LSE) . This means the current 100 attempts would almost never be taken on those platforms, and thus we can avoid introducing any platform-specific test config selection.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From lancea at openjdk.org  Tue Aug 30 16:17:14 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 30 Aug 2022 16:17:14 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
Message-ID: <ZGY3GBR3Ip4XzMt6uXuy2VgllM_I7kNpzjhGYlvD1BI=.c0917de2-8dc0-42a2-9c74-9e10b4025a61@github.com>

On Mon, 29 Aug 2022 11:58:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JavaDoc according to @mbreinhold's suggestions

Volker,

Thank you for your patience while we worked through all of the nuances of this 

The changes look good to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7986

From aturbanov at openjdk.org  Tue Aug 30 17:34:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 30 Aug 2022 17:34:11 GMT
Subject: Integrated: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <CoKzSrLF8f6z5GSpOqtJwwcS51FNEdqbHIPq8xFs21U=.84718ad4-a64f-480b-872b-2c49b270b47f@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

This pull request has now been integrated.

Changeset: d3d2e669
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3d2e669b7bdfbd91cab7b918bc62cf1879cc95b
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8293009: Remove unused field 'millisPerHour' in DateFormatSymbols

Reviewed-by: naoto, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10005

From duke at openjdk.org  Tue Aug 30 18:32:35 2022
From: duke at openjdk.org (Ryan Flegel)
Date: Tue, 30 Aug 2022 18:32:35 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <klezV_eq91b53Wn-QJfZXQvPPG7A72S2UpV890CCW8Y=.2cb4092b-84a0-41ea-bfac-e1451f8d158d@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

Will this fix be back-ported to JDK 8/11/17?

-------------

PR: https://git.openjdk.org/jdk/pull/6043

From rriggs at openjdk.org  Tue Aug 30 18:33:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 Aug 2022 18:33:24 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
 [v2]
In-Reply-To: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
Message-ID: <cytpsxC9SqxBaZgmRdzaickPRbrr4jw1jqBiO3DvTh4=.66b513fd-766d-483d-82a8-9d426a35a14e@github.com>

> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
> The extensively relies on references processing and invokes GC on a very short cycle.
> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
> 
> The delay between gc requests is extended to 200ms and the tests pass reliably.
> There are small improvements in diagnostic messages and cleanup of unused imports.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup of messages that describe the cleaning function to be run or not.
  Switched to using jtreg @enablePreview.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10048/files
  - new: https://git.openjdk.org/jdk/pull/10048/files/8dee8e8f..d98a3b02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10048&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10048&range=00-01

  Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10048/head:pull/10048

PR: https://git.openjdk.org/jdk/pull/10048

From shade at openjdk.org  Tue Aug 30 18:46:31 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Aug 2022 18:46:31 GMT
Subject: RFR: 8293020: jmod should not be treated as "small" tool for large
 modules [v3]
In-Reply-To: <etz27VpnUHqJ1AdcGOfWiskyz4LnKzde1hakrPc7f0U=.e210edcb-90ce-4c1a-bf65-4a4b9dc9ee4f@github.com>
References: <LsH5JXKXWGS_BYs9nSuEqcLmdDXWN8A2N9UazgbL9ME=.285a00b6-217d-4c3f-84c2-2fc04295da8a@github.com>
 <etz27VpnUHqJ1AdcGOfWiskyz4LnKzde1hakrPc7f0U=.e210edcb-90ce-4c1a-bf65-4a4b9dc9ee4f@github.com>
Message-ID: <ajEvNIiZmYz3znhrEqcicnv5ibOl7G5sqrtyF6ISZe0=.db817b61-dbd5-4a79-8b4a-4e3a2b734223@github.com>

On Mon, 29 Aug 2022 18:01:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is similar to [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket change to allow all modules be compiled with default options is a net loss. Instead, we can hand-pick the major offenders (large modules) where running jmod with normal tool options improves performance.
>> 
>> I instrumented the jmod to tell me the times it needs to create individual modules, and hand-picked three top modules that take multiple seconds to run.
>> 
>> Motivational `make clean-images images` times:
>> 
>> 
>> # x86_64 Server, release
>> 
>> # Baseline
>> real	0m12.040s
>> user	1m4.872s
>> sys	0m10.805s
>> 
>> # Patched
>> real	0m10.785s  ; <--- 1.2s faster
>> user	1m7.031s
>> sys	0m10.985s
>> 
>> # x86_64 Server, fastdebug
>> 
>> # Baseline
>> real	0m19.263s
>> user	2m42.317s
>> sys	0m18.537s
>> 
>> # Patched
>> real	0m17.911s ;  <--- 1.1s faster
>> user	2m52.810s
>> sys	0m19.092s
>> 
>> 
>> # x86_64 Server, slowdebug
>> 
>> # Baseline
>> real	0m44.799s
>> user	10m7.106s
>> sys	0m17.578s
>> 
>> # Patched
>> real	0m46.975s   ; <--- 2.5 sec slower
>> user	11m1.155s
>> sys	0m17.060s
>> 
>> 
>> I think we can accept the `slowdebug` regression in favor of improvements on `release` and `fastdebug` that most people seem to be building every day.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use :=

If anyone from core-libs crowd wants to chime in, welcome. Otherwise, I'll integrate soon.

-------------

PR: https://git.openjdk.org/jdk/pull/10062

From smarks at openjdk.org  Tue Aug 30 19:01:57 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 30 Aug 2022 19:01:57 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
Message-ID: <lXu3PA8YN1KgHiqlHijmY6j5mXhDA3OJIOTYzOZinhE=.f0337b85-b258-41ea-aef7-c19ac712c561@github.com>

On Mon, 29 Aug 2022 13:49:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

Spec looks good. Let me know when you're done updating the CSR so I can mark it reviewed.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From alanb at openjdk.org  Tue Aug 30 19:03:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Aug 2022 19:03:13 GMT
Subject: RFR: 8293020: jmod should not be treated as "small" tool for large
 modules [v3]
In-Reply-To: <etz27VpnUHqJ1AdcGOfWiskyz4LnKzde1hakrPc7f0U=.e210edcb-90ce-4c1a-bf65-4a4b9dc9ee4f@github.com>
References: <LsH5JXKXWGS_BYs9nSuEqcLmdDXWN8A2N9UazgbL9ME=.285a00b6-217d-4c3f-84c2-2fc04295da8a@github.com>
 <etz27VpnUHqJ1AdcGOfWiskyz4LnKzde1hakrPc7f0U=.e210edcb-90ce-4c1a-bf65-4a4b9dc9ee4f@github.com>
Message-ID: <ditSp538jNTngHMufsMmM7nQyh3P_pcCFMI7IsYGxj4=.2cc2f8af-29ca-417f-8c0f-be4d538b0255@github.com>

On Mon, 29 Aug 2022 18:01:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is similar to [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket change to allow all modules be compiled with default options is a net loss. Instead, we can hand-pick the major offenders (large modules) where running jmod with normal tool options improves performance.
>> 
>> I instrumented the jmod to tell me the times it needs to create individual modules, and hand-picked three top modules that take multiple seconds to run.
>> 
>> Motivational `make clean-images images` times:
>> 
>> 
>> # x86_64 Server, release
>> 
>> # Baseline
>> real	0m12.040s
>> user	1m4.872s
>> sys	0m10.805s
>> 
>> # Patched
>> real	0m10.785s  ; <--- 1.2s faster
>> user	1m7.031s
>> sys	0m10.985s
>> 
>> # x86_64 Server, fastdebug
>> 
>> # Baseline
>> real	0m19.263s
>> user	2m42.317s
>> sys	0m18.537s
>> 
>> # Patched
>> real	0m17.911s ;  <--- 1.1s faster
>> user	2m52.810s
>> sys	0m19.092s
>> 
>> 
>> # x86_64 Server, slowdebug
>> 
>> # Baseline
>> real	0m44.799s
>> user	10m7.106s
>> sys	0m17.578s
>> 
>> # Patched
>> real	0m46.975s   ; <--- 2.5 sec slower
>> user	11m1.155s
>> sys	0m17.060s
>> 
>> 
>> I think we can accept the `slowdebug` regression in favor of improvements on `release` and `fastdebug` that most people seem to be building every day.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use :=

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10062

From smarks at openjdk.org  Tue Aug 30 19:24:07 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 30 Aug 2022 19:24:07 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
Message-ID: <cUdJ3axIca0IZFAtgty2lbOpO5UkVYYSUoCb1-C52Wg=.a302119a-8513-44f5-a8b5-01a314a21e72@github.com>

On Mon, 29 Aug 2022 13:49:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

test/jdk/java/util/regex/NamedGroupsTests.java line 51:

> 49:         testMatchResultStartEndGroup2();
> 50:         testMatchResultStartEndGroup3();
> 51:     }

The three numbered tests here are a little hard to follow. Looks like these tests are

1. test existing group names, with no match
2. test existing group names, with a successful match
3. test nonexistent group names, with a successful match

On test names, sometimes people provide extremely verbose test names such as `testThatExistingGroupNameWithMatchReturnsNegativeOrNull` which I think is overkill, but having a name that's somewhat descriptive would be helpful.

It looks like a case is missing, which is a test for a nonexistent group name on a MatchResult that doesn't have a successful match. I'm not sure which is checked first; I think the implementation would throw IAE, because of the nonexistent name, regardless of whether or not the MatchResult has a match.

However, I don't think we've specified this, and in fact I don't think we want to. In general though, if multiple error conditions can arise in the same operation, the general style is not to constrain implementations to check for things in a particular order. Thus either IAE or ISE would be acceptable. Perhaps a test should be added for that. (Hm, might want to take another look at the specs regarding this issue.)

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Tue Aug 30 19:31:12 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 30 Aug 2022 19:31:12 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
Message-ID: <SbuNMzINPAZ73x8YKPkMvR904iSGYN3OyKCROSTLz6s=.8ccd8027-8084-426c-b243-1c9f50aa2052@github.com>

On Mon, 29 Aug 2022 13:49:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

test/jdk/java/util/regex/NamedGroupsTests.java line 45:

> 43: 
> 44:         testMatchResultStartEndGroup();
> 45:     }

I haven't gone through all the tests in great detail (yet), but it occurs to me that we potentially have THREE implementations of some of the logic, and strictly speaking we should test all the code paths. The three implementations are in:

1. Matcher
2. Matcher$ImmutableMatchResult
3. MatchResult's default methods

I took a quick look and it looks like Matcher and Matcher$ImmutableMatchResult override the default methods, so the default methods themselves need to be tested. This is essentially testing the `@implSpec`. The typical way to do that is to have the test create its own MatchResult implementation(s). There might need to be implementations that do and do not implement `namedGroups`, in order to test UOE. They might also need some state to cover various cases of no-match, has-match with and without group names, etc.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Tue Aug 30 20:21:17 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Tue, 30 Aug 2022 20:21:17 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <SbuNMzINPAZ73x8YKPkMvR904iSGYN3OyKCROSTLz6s=.8ccd8027-8084-426c-b243-1c9f50aa2052@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
 <SbuNMzINPAZ73x8YKPkMvR904iSGYN3OyKCROSTLz6s=.8ccd8027-8084-426c-b243-1c9f50aa2052@github.com>
Message-ID: <szl4_WFAGjIt6pfkUEt1AzyMkZVHbzjfqQBisUHyZG0=.4cee8020-6676-4c6e-a6ce-ffd58b02ee3b@github.com>

On Tue, 30 Aug 2022 19:27:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8065554: MatchResult should provide values of named-capturing groups
>
> test/jdk/java/util/regex/NamedGroupsTests.java line 45:
> 
>> 43: 
>> 44:         testMatchResultStartEndGroup();
>> 45:     }
> 
> I haven't gone through all the tests in great detail (yet), but it occurs to me that we potentially have THREE implementations of some of the logic, and strictly speaking we should test all the code paths. The three implementations are in:
> 
> 1. Matcher
> 2. Matcher$ImmutableMatchResult
> 3. MatchResult's default methods
> 
> I took a quick look and it looks like Matcher and Matcher$ImmutableMatchResult override the default methods, so the default methods themselves need to be tested. This is essentially testing the `@implSpec`. The typical way to do that is to have the test create its own MatchResult implementation(s). There might need to be implementations that do and do not implement `namedGroups`, in order to test UOE. They might also need some state to cover various cases of no-match, has-match with and without group names, etc.

An implementation that overrides `namedGroups` without overriding the other methods accepting group names is `Matcher$ImmutableMatchResult`, which is already exercised in the tests.

> (Hm, might want to take another look at the specs regarding this issue.)

Not sure who wants to take another look. If that it's you, then I'll wait with the CSR.
I'll change the method names to something a bit more speaking.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From smarks at openjdk.org  Tue Aug 30 21:11:00 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 30 Aug 2022 21:11:00 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <szl4_WFAGjIt6pfkUEt1AzyMkZVHbzjfqQBisUHyZG0=.4cee8020-6676-4c6e-a6ce-ffd58b02ee3b@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
 <SbuNMzINPAZ73x8YKPkMvR904iSGYN3OyKCROSTLz6s=.8ccd8027-8084-426c-b243-1c9f50aa2052@github.com>
 <szl4_WFAGjIt6pfkUEt1AzyMkZVHbzjfqQBisUHyZG0=.4cee8020-6676-4c6e-a6ce-ffd58b02ee3b@github.com>
Message-ID: <FYIIPVoDatNWgVbZ-CB-DQYulFmxo1m-OQX3CWWfrSQ=.4d43f579-34b6-4d28-97df-4d1848f127e1@github.com>

On Tue, 30 Aug 2022 20:17:04 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> test/jdk/java/util/regex/NamedGroupsTests.java line 45:
>> 
>>> 43: 
>>> 44:         testMatchResultStartEndGroup();
>>> 45:     }
>> 
>> I haven't gone through all the tests in great detail (yet), but it occurs to me that we potentially have THREE implementations of some of the logic, and strictly speaking we should test all the code paths. The three implementations are in:
>> 
>> 1. Matcher
>> 2. Matcher$ImmutableMatchResult
>> 3. MatchResult's default methods
>> 
>> I took a quick look and it looks like Matcher and Matcher$ImmutableMatchResult override the default methods, so the default methods themselves need to be tested. This is essentially testing the `@implSpec`. The typical way to do that is to have the test create its own MatchResult implementation(s). There might need to be implementations that do and do not implement `namedGroups`, in order to test UOE. They might also need some state to cover various cases of no-match, has-match with and without group names, etc.
>
> An implementation that overrides `namedGroups` without overriding the other methods accepting group names is `Matcher$ImmutableMatchResult`, which is already exercised in the tests.

OK, as long as all the code paths are covered.

>> test/jdk/java/util/regex/NamedGroupsTests.java line 51:
>> 
>>> 49:         testMatchResultStartEndGroup2();
>>> 50:         testMatchResultStartEndGroup3();
>>> 51:     }
>> 
>> The three numbered tests here are a little hard to follow. Looks like these tests are
>> 
>> 1. test existing group names, with no match
>> 2. test existing group names, with a successful match
>> 3. test nonexistent group names, with a successful match
>> 
>> On test names, sometimes people provide extremely verbose test names such as `testThatExistingGroupNameWithMatchReturnsNegativeOrNull` which I think is overkill, but having a name that's somewhat descriptive would be helpful.
>> 
>> It looks like a case is missing, which is a test for a nonexistent group name on a MatchResult that doesn't have a successful match. I'm not sure which is checked first; I think the implementation would throw IAE, because of the nonexistent name, regardless of whether or not the MatchResult has a match.
>> 
>> However, I don't think we've specified this, and in fact I don't think we want to. In general though, if multiple error conditions can arise in the same operation, the general style is not to constrain implementations to check for things in a particular order. Thus either IAE or ISE would be acceptable. Perhaps a test should be added for that. (Hm, might want to take another look at the specs regarding this issue.)
>
>> (Hm, might want to take another look at the specs regarding this issue.)
> 
> Not sure who wants to take another look. If that it's you, then I'll wait with the CSR.
> I'll change the method names to something a bit more speaking.

Sorry I should have been more specific. "Somebody" should take another look. :-) Well, anyway, I did, and the specification as written does not indicate which error condition is checked first. I think this is OK, so I don't think any changes are necessary. You might mention this in the text of the CSR; I know that Joe and I have discussed this issue previously, and he might have a recommendation.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From darcy at openjdk.org  Tue Aug 30 21:59:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Aug 2022 21:59:10 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <D5aefTnEewXyKU1G-uga7fyU4_v9mYxW-n4JC8iwJOk=.0be3f8fe-cf38-4032-b39a-40312b620277@github.com>
Message-ID: <nXgp52vhSkJctHnSl33uPP1F0kDJERU4-7QRZRZX_UI=.957ce4e7-7793-46d5-a62d-cc1cea80b9cc@github.com>

On Tue, 30 Aug 2022 06:26:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Update to remove support for -source/-target/--release 7 from javac.
>> 
>> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.
>
> test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28:
> 
>> 26:  * @bug 8009267
>> 27:  * @summary Verify uses of isAnnotationPresent compile under older source versions
>> 28:  * @compile OldenCompilingWithDefaults.java
> 
> I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now.

Certainly less useful than it once was!

I can remove it in the next push.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From shade at openjdk.org  Wed Aug 31 05:34:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 Aug 2022 05:34:16 GMT
Subject: Integrated: 8293020: jmod should not be treated as "small" tool for
 large modules
In-Reply-To: <LsH5JXKXWGS_BYs9nSuEqcLmdDXWN8A2N9UazgbL9ME=.285a00b6-217d-4c3f-84c2-2fc04295da8a@github.com>
References: <LsH5JXKXWGS_BYs9nSuEqcLmdDXWN8A2N9UazgbL9ME=.285a00b6-217d-4c3f-84c2-2fc04295da8a@github.com>
Message-ID: <YmG7QYsyF6oTpFICuqImtpeZ8F8ZH4TEM_shQo6_Ous=.a724b5ba-cb67-4efa-b99f-e06670962f17@github.com>

On Mon, 29 Aug 2022 10:13:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is similar to [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket change to allow all modules be compiled with default options is a net loss. Instead, we can hand-pick the major offenders (large modules) where running jmod with normal tool options improves performance.
> 
> I instrumented the jmod to tell me the times it needs to create individual modules, and hand-picked three top modules that take multiple seconds to run.
> 
> Motivational `make clean-images images` times:
> 
> 
> # x86_64 Server, release
> 
> # Baseline
> real	0m12.040s
> user	1m4.872s
> sys	0m10.805s
> 
> # Patched
> real	0m10.785s  ; <--- 1.2s faster
> user	1m7.031s
> sys	0m10.985s
> 
> # x86_64 Server, fastdebug
> 
> # Baseline
> real	0m19.263s
> user	2m42.317s
> sys	0m18.537s
> 
> # Patched
> real	0m17.911s ;  <--- 1.1s faster
> user	2m52.810s
> sys	0m19.092s
> 
> 
> # x86_64 Server, slowdebug
> 
> # Baseline
> real	0m44.799s
> user	10m7.106s
> sys	0m17.578s
> 
> # Patched
> real	0m46.975s   ; <--- 2.5 sec slower
> user	11m1.155s
> sys	0m17.060s
> 
> 
> I think we can accept the `slowdebug` regression in favor of improvements on `release` and `fastdebug` that most people seem to be building every day.

This pull request has now been integrated.

Changeset: d2eed079
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2eed079c35022b61be28f7111612ecdcb3c2b30
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

8293020: jmod should not be treated as "small" tool for large modules

Reviewed-by: erikj, ihse, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10062

From duke at openjdk.org  Wed Aug 31 05:51:09 2022
From: duke at openjdk.org (liach)
Date: Wed, 31 Aug 2022 05:51:09 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <1K85uSytblPO01nn-KY8v2-9TjTtIc_BrBWsqeltmok=.f1f48df5-359b-4984-b47f-f123f7e1c164@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach 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:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

Let's wait

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From shade at openjdk.org  Wed Aug 31 08:07:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 Aug 2022 08:07:11 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <bHeg5aBjvQxuSvi1UjQBmXG-r_taV6pn53xN08Mx3yo=.665f36d3-f656-468d-904a-5f9f04dde8ca@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <bHeg5aBjvQxuSvi1UjQBmXG-r_taV6pn53xN08Mx3yo=.665f36d3-f656-468d-904a-5f9f04dde8ca@github.com>
Message-ID: <QKoEMnS5UaEO3pBhtO1rOzY0mThmX4nxxYvgZmsOGzk=.f5b7d0c3-5095-4f61-8b60-2b93ee2f1ab7@github.com>

On Mon, 22 Aug 2022 17:43:43 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Rework timeouts
>>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>>  - Update copyrights
>>  - Also do Unsafe tests
>>  - Fix
>
> It's awkward to manage this across various hardware, esp. if the hardware is less mature (perhaps combined with a less mature HotSpot implementation). The approach looks reasonable, but it would be nice if we could just increase the retries and waiting values on weak LL/SC hardware or at least follow up with something like that later on.
> 
> As a quick experiment could we annotate fields with `@Contended` and see if that reduces the number of retries?

@PaulSandoz, @TheRealMDoerr -- are you okay with this?

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From aturbanov at openjdk.org  Wed Aug 31 08:46:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 08:46:32 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation [v2]
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
  
  use private for methods which changed signature

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10007/files
  - new: https://git.openjdk.org/jdk/pull/10007/files/a53bcac0..e85e3c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10007&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10007&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10007/head:pull/10007

PR: https://git.openjdk.org/jdk/pull/10007

From aturbanov at openjdk.org  Wed Aug 31 08:46:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 08:46:32 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation [v2]
In-Reply-To: <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
Message-ID: <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>

On Tue, 30 Aug 2022 08:58:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>>   
>>   use private for methods which changed signature
>
> src/java.base/share/classes/java/text/PatternEntry.java line 55:
> 
>> 53:      * Gets the current extension, quoted
>> 54:      */
>> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {
> 
> Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?

Changed a few of methods to `private`

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From dfuchs at openjdk.org  Wed Aug 31 08:54:08 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 Aug 2022 08:54:08 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
 [v2]
In-Reply-To: <cytpsxC9SqxBaZgmRdzaickPRbrr4jw1jqBiO3DvTh4=.66b513fd-766d-483d-82a8-9d426a35a14e@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
 <cytpsxC9SqxBaZgmRdzaickPRbrr4jw1jqBiO3DvTh4=.66b513fd-766d-483d-82a8-9d426a35a14e@github.com>
Message-ID: <v5KkE-LLuJMjNA_1rpZ4x0eiualsbAasOcMOPGIVAYc=.4504dc8d-f574-4afc-b261-aba2f684dbd3@github.com>

On Tue, 30 Aug 2022 18:33:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
>> The extensively relies on references processing and invokes GC on a very short cycle.
>> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
>> 
>> The delay between gc requests is extended to 200ms and the tests pass reliably.
>> There are small improvements in diagnostic messages and cleanup of unused imports.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup of messages that describe the cleaning function to be run or not.
>   Switched to using jtreg @enablePreview.

Thaks @RogerRiggs - the new messages LGTM.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10048

From simonis at openjdk.org  Wed Aug 31 09:06:10 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 31 Aug 2022 09:06:10 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v10]
In-Reply-To: <5LOH-9ywUPltn3Xnt9KUy8fzSqStQRbbM3MMhTxqHYA=.942a1d30-df54-4d9e-add8-c650f123abf3@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>
 <5LOH-9ywUPltn3Xnt9KUy8fzSqStQRbbM3MMhTxqHYA=.942a1d30-df54-4d9e-add8-c650f123abf3@github.com>
Message-ID: <r_hbDDFejaoBKcACTv8dxdej-MqrrroyMheUIb_66bQ=.a52bced0-9258-47f1-918e-6b715adb9e4e@github.com>

On Thu, 21 Jul 2022 17:45:39 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> First, I?ll observe that there is no specification conflict here.  The specifications of `InflaterInputStream::read(byte[] b, int off, int len)` and `Inflater::inflate(byte[] b, int off, int len)` are not in conflict at all.  The latter is simply weaker than the former.
> 
> What is true is that if you build the JDK in the default manner, without any patches, then what you wind up with is an `InflaterInputStream::read(...)` implementation that satisfies the inherited `InputStream::read(...)` specification, including the constraint that a read operation must not _scribble_ in the caller?s output buffer, _i.e._, modify any byte in that buffer beyond the returned byte count.  (That constraint is, so far as we know, satisfied by every `InputStream` subclass defined in the JDK.)
> 
> A default JDK build?s `InflaterInputStream::read(...)` method doesn?t scribble because
> 
>   - The implementation of `InflaterInputStream::read(...)` assumes that the implementation of `Inflater::inflate(...)` doesn?t scribble, and
> 
>   - The implementation of `Inflater::inflate(...)` satisfies that assumption because it invokes the corresponding function in the [standard native Zip implementation](https://zlib.net/), which itself doesn?t scribble.
> 
> So, not only does the specification forbid `InflaterInputStream::read(...)` from scribbling, but in the official Java SE Reference Implementation ? which is simply a default JDK build ? that method does not scribble.  (Perhaps by accident, but that is immaterial here.)
> 
> Therefore, if in your own JDK build you substitute an alternative Zip implementation whose `inflate` function does scribble then you wind up with a JDK that both violates the specification and behaves differently than the RI.  It is incompatible.  If you use such a JDK in production then you risk breaking existing code.
> 
> Now, compatibility is one of the key values of the Java Platform, but performance is not unimportant.  Is there something we can do to accommodate [alternative, faster, scribbling Zip implementations][faster-zlib]?
> 
> @simonis lists three options in the [issue].  I?ll cast the options somewhat differently.
> 
>   1. Do not change the specification in any way.  The specification text that forbids scribbling dates back to Java 1.1, released over 25 years ago.  (Arguably that text over-specifies the `InputStream::read(...)` method, but that is also immaterial.)  It?s all too possible that existing code ? no matter how odd or poorly written we think it might be ? depends upon this constraint.
> 
>      With this option, a JDK build that uses a scribbling Zip implementation would have to buffer that implementation?s output and copy only the returned number of bytes into the caller?s buffer.  This would degrade any performance benefit.
> 
>   2. Weaken the specification of `InflaterInputStream` ? and, thereby, that of its subclasses `GZipInputStream` and `ZipInputStream` ? to allow scribbling.  This is essentially @simonis?s initial suggestion, as embodied in [63ae357] earlier in this PR.
> 
>      This option risks breaking existing code that depends upon the 25-year-old promise that `InflaterInputStream::read(...)` will not scribble.  Changing the specification of an indirect subclass of `InputStream`, moreover, is apt to go unnoticed by many developers, who routinely deal with instances of `InputStream` without any knowledge of those instances? concrete classes.  (@jaikiran gives one example above.)
> 
>   3. Weaken the specification of the `InputStream::read(...)` method to allow scribbling, as [suggested by @jddarcy in the CSR][jddarcy].
> 
>      This option is at least as risky to existing code as the second option, though it?s marginally more likely that developers writing new code will notice the specification change.
> 
>      What?s worse, however, is that this option gives developers writing new subclasses of `InputStream` permission to deviate from both that class?s longstanding specification and the actual behavior of every `InputStream` subclass defined in the JDK.  In the long term, that could wreak subtle bugs throughout the ecosystem, even breaking code that does absolutely nothing with Zip-related input streams.
> 
> In favor of both the second and third options is @simonis?s statement above that his employer (Amazon) has used JDK builds with a scribbling Zip implementation in production for two years.  He has further elaborated (privately) that this includes hundreds of services built with many of the usual popular frameworks and libraries (Spring, Hibernate, ASM, etc.).  This suggests that the practical impact, out in the wild, of allowing scribbling Zip implementations is acceptable.
> 
> On that basis I am ? just barely ? comfortable with the second option, _i.e._, weakening the specification of `InflaterInputStream` to allow scribbling, thereby contradicting the specification of its `InputStream` superclass.
> 
> Explicitly specifying a subclass in a way that?s inconsistent with the specification of one of its superclasses is generally a really bad idea.  It violates the [Liskov Substitution Principle][lsp], which enables instances of a subclass to be substituted freely for instances of one of its superclasses.  Thus we do not condone such changes lightly.  There are, however, precedents in a handful of special cases in the Java Platform; _e.g._, in the [`java.util.IdentityHashMap`][ihm] and [`java.sql.Timestamp`][ts] classes.
> 
> The third option above would not violate the Liskov substitution principle, but in my view could prove more harmful in the long run.
> 
> Recommendations:
> 
>   - Revert this PR back to [63ae357], and make corresponding updates to the [issue] and the [CSR].
> 
>   - Additionally, find every method in every `java.*` class that?s declared to return an `InputStream` (_e.g._, `ZipFile::getInputStream(...)` but actually returns an instance of `InflaterInputStream` or one of its subclasses.  Add an API note to each such method to let developers know that the returned input stream might scribble, per @jaikiran?s suggestion above.  These notes can all use the same text, linking to the revised `InflaterInputStream::read(...)` specification.
> 
>   - Revise the summary of this PR, the issue, and the CSR to reflect the true nature of the proposed change rather than assert a nonexistent conflict.  Consider ?Weaken the `InflaterInputStream` specification in order to allow faster Zip implementations?.
> 
>   - Change the issue type from a bug ? which it?s not ? to an enhancement.
> 
>   - Create a related release-note issue, as @RogerRiggs suggests above.
> 
> 
> [faster-zlib]: https://github.com/simonis/zlib-chromium#inflater-improvements-in-zlib-chromium
> [issue]: https://bugs.openjdk.org/browse/JDK-8282648
> [63ae357]: https://github.com/openjdk/jdk/pull/7986/commits/63ae3572da674a0926bb9d0adcea88d89bb56707
> [jddarcy]: https://bugs.openjdk.org/browse/JDK-8283758?focusedCommentId=14492930&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492930
> [CSR]: https://bugs.openjdk.org/browse/JDK-8283758
> [lsp]: https://en.wikipedia.org/wiki/Liskov_substitution_principle
> [ihm]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/IdentityHashMap.html
> [ts]: https://docs.oracle.com/en/java/javase/18/docs/api/java.sql/java/sql/Timestamp.html

@mbreinhold, @LanceAndersen thanks for your reviews. I'm waiting for the CSR approval before pushing.

-------------

PR: https://git.openjdk.org/jdk/pull/7986

From duke at openjdk.org  Wed Aug 31 13:26:32 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 31 Aug 2022 13:26:32 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v5]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>

> Add support for named groups to java.util.regex.MatchResult

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8065554: MatchResult should provide values of named-capturing groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/e7e29553..365a01eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=03-04

  Stats: 160 lines in 1 file changed: 104 ins; 22 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Wed Aug 31 13:26:32 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 31 Aug 2022 13:26:32 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v4]
In-Reply-To: <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <uWVxhMWDTxmhcBmivnGgK22pMYaoB9zYOeYIOHWExsQ=.20dc87ba-7d2e-4107-afdc-ea2119f8e575@github.com>
Message-ID: <50BcP8ULZxwdnnyIhc0ltHrEXju_T2H8zdYjaFT7MtU=.bbc7c9c1-8e2c-44b7-9c6b-9e4f7d0cc024@github.com>

On Mon, 29 Aug 2022 13:49:52 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

Added an implementation of `MatchResult` in the test class that does not override any of the default methods.
More speaking method names.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From rriggs at openjdk.org  Wed Aug 31 13:34:23 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 Aug 2022 13:34:23 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation [v2]
In-Reply-To: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
Message-ID: <9hhJhKV_ZZHpLSbWcewBI-3VrkZPQyiue94UJvsiqR0=.278656fb-0770-4b34-931c-435384d2b009@github.com>

On Wed, 31 Aug 2022 08:46:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
>> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>   
>   use private for methods which changed signature

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From alanb at openjdk.org  Wed Aug 31 13:59:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Aug 2022 13:59:12 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
Message-ID: <rw4JyT02eA5X5U45C7uPd1RRoUOmRHmArWCnuKk8s9A=.9a08b879-de9b-4a21-bedb-589b48c6bd2f@github.com>

On Mon, 29 Aug 2022 11:58:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JavaDoc according to @mbreinhold's suggestions

The update in d82c7526 looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7986

From aturbanov at openjdk.org  Wed Aug 31 14:00:33 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 14:00:33 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation [v2]
In-Reply-To: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
Message-ID: <9J9DTL4GgD0jgjeYTMii-8cWRpeRe6KfQaNlPr6jUVM=.7043c1a3-c89f-42be-91cf-7f30c3e18b7f@github.com>

On Wed, 31 Aug 2022 08:46:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
>> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>   
>   use private for methods which changed signature

Thank you for review!

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From aturbanov at openjdk.org  Wed Aug 31 14:00:34 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 14:00:34 GMT
Subject: Integrated: 8293008: Replace uses of StringBuffer with StringBuilder
 in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <e-eO9kJOLT264V9HoTRg4XeFR-pCT9t4AXGzdxxJSAo=.a1e0a9fa-d696-4959-bce5-d0f12fb80f66@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

This pull request has now been integrated.

Changeset: 0d51f63a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d51f63a2e95976636f8ec74a69096791304724e
Stats:     9 lines in 2 files changed: 0 ins; 0 del; 9 mod

8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation

Reviewed-by: rriggs, naoto, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10007

From duke at openjdk.org  Wed Aug 31 14:12:09 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 31 Aug 2022 14:12:09 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v5]
In-Reply-To: <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
Message-ID: <18SYRjpsbDFpEC5VEbFyJj47XyBvMyXqdFdlSjL1a68=.86d14b1e-ff41-46a4-b6ac-010ffa0a0e6c@github.com>

On Wed, 31 Aug 2022 13:26:32 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

CSR updated to current status.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From naoto at openjdk.org  Wed Aug 31 17:14:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 Aug 2022 17:14:59 GMT
Subject: RFR: 8293154: TemporalQueries java doc error
Message-ID: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>

Simple doc fix.

-------------

Commit messages:
 - 8293154: TemporalQueries java doc error

Changes: https://git.openjdk.org/jdk/pull/10103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293154
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10103.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10103/head:pull/10103

PR: https://git.openjdk.org/jdk/pull/10103

From vromero at openjdk.org  Wed Aug 31 17:17:07 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 31 Aug 2022 17:17:07 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

looks good to me

the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10074

From rriggs at openjdk.org  Wed Aug 31 17:22:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 Aug 2022 17:22:05 GMT
Subject: RFR: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <l1aJ3rjZ6DL5WTYCLz-xWVW9wv--_DCqnyhcZ2nWtm4=.4ac9b4a9-e6ad-4402-a295-19e5d58742ba@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10103

From darcy at openjdk.org  Wed Aug 31 17:25:09 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 Aug 2022 17:25:09 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac
In-Reply-To: <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
 <LhYwbXuOrtQEJvkqlQNR3t-_BLDv8DpUgdsw6vzQ54w=.f5ee0ac8-fe04-4f17-9393-158580c87a37@github.com>
Message-ID: <HWqiwIzAeBCWpReez9PDRGQuEq0yk2sniFjbWvisOPo=.24b59d46-b238-46d4-8cba-79d5a8dcc4ee@github.com>

On Wed, 31 Aug 2022 17:13:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself

Thanks Vicente; I assigned

    JDK-8293051: Further refactor javac after removal of -source/-target/--release 7

to you.

-------------

PR: https://git.openjdk.org/jdk/pull/10074

From lancea at openjdk.org  Wed Aug 31 17:26:07 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 31 Aug 2022 17:26:07 GMT
Subject: RFR: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <A65eUqBfQSXAiyQvpWO4TqZ-8dU4Vv1SqZwdczNr_d8=.55115dff-8393-4ed8-bbb7-c426fe3c11e9@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10103

From psandoz at openjdk.org  Wed Aug 31 19:41:26 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 31 Aug 2022 19:41:26 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v7]
In-Reply-To: <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
Message-ID: <jmYV__FzEwUOLwpUyzuuu3JQ6oTa2w3NVlhGuvVx1hI=.e78416a1-4f5a-4ad4-98d3-5743e7649bc6@github.com>

On Tue, 30 Aug 2022 14:18:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Rewind back to 100 attempts, 1ms delay
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Pull Handles.get out of the weak retry loop
>  - Drop weakDelay to 1
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b3450e93...fd6aa17b

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From psandoz at openjdk.org  Wed Aug 31 19:41:27 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 31 Aug 2022 19:41:27 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <QKoEMnS5UaEO3pBhtO1rOzY0mThmX4nxxYvgZmsOGzk=.f5b7d0c3-5095-4f61-8b60-2b93ee2f1ab7@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <bHeg5aBjvQxuSvi1UjQBmXG-r_taV6pn53xN08Mx3yo=.665f36d3-f656-468d-904a-5f9f04dde8ca@github.com>
 <QKoEMnS5UaEO3pBhtO1rOzY0mThmX4nxxYvgZmsOGzk=.f5b7d0c3-5095-4f61-8b60-2b93ee2f1ab7@github.com>
Message-ID: <u1YJ2SIgg2IYas1-d6owp-X6I33FykRvgMwUpMlO6po=.74a6ad12-f1a3-4114-bb69-3b9f93d55401@github.com>

On Wed, 31 Aug 2022 08:05:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It's awkward to manage this across various hardware, esp. if the hardware is less mature (perhaps combined with a less mature HotSpot implementation). The approach looks reasonable, but it would be nice if we could just increase the retries and waiting values on weak LL/SC hardware or at least follow up with something like that later on.
>> 
>> As a quick experiment could we annotate fields with `@Contended` and see if that reduces the number of retries?
>
> @PaulSandoz, @TheRealMDoerr -- are you okay with this?

@shipilev yes, seems reasonable, since spurious failures are rare on other platforms. Good effort digging into the RISC-V issues.

-------------

PR: https://git.openjdk.org/jdk/pull/9889

From duke at openjdk.org  Wed Aug 31 20:23:53 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 31 Aug 2022 20:23:53 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent
Message-ID: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>

The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
- root node 
- element nodes 
- text nodes 
- attribute nodes 
- namespace nodes 
- comment nodes

-------------

Commit messages:
 - Add document root tests
 - Added relative parent tests.
 - Initial commit.

Changes: https://git.openjdk.org/jdk/pull/10107/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292990
  Stats: 160 lines in 2 files changed: 160 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10107.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10107/head:pull/10107

PR: https://git.openjdk.org/jdk/pull/10107

From duke at openjdk.org  Wed Aug 31 20:23:53 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 31 Aug 2022 20:23:53 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent
In-Reply-To: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
Message-ID: <1Ijej4pPNUpMyip-YzDmT0PmTet-NQlLlrl8C2xYia0=.a07cd345-9604-43cb-9804-2a0b7cd10306@github.com>

On Wed, 31 Aug 2022 20:16:33 GMT, Bill Huang <duke at openjdk.org> wrote:

> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
> - root node 
> - element nodes 
> - text nodes 
> - attribute nodes 
> - namespace nodes 
> - comment nodes

@JoeWang-Java Hi Joe, could you please review this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/10107

From darcy at openjdk.org  Wed Aug 31 21:09:13 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 Aug 2022 21:09:13 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
Message-ID: <wkJxgzgxGxONYFioHAYNg-to3e2XtwDfvk5TSO-Z_Ac=.aab06671-d4e8-42d0-9b99-6189733fe812@github.com>

On Mon, 29 Aug 2022 11:58:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated JavaDoc according to @mbreinhold's suggestions

src/java.base/share/classes/java/util/jar/JarInputStream.java line 170:

> 168: 
> 169:     /**
> 170:      * Reads from the current ZIP entry into an array of bytes, returning the number of

Please change "Reads from the current ZIP entry..." to "Reads from the current JAR entry..."

-------------

PR: https://git.openjdk.org/jdk/pull/7986

From mchhipa at openjdk.org  Wed Aug 31 21:17:22 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 31 Aug 2022 21:17:22 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v3]
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <K3YKARq-_Al183mGt7yeJ4PHcXdzmC5oYEkfhyl060k=.0a13a3a6-3596-4a62-b9fd-39f6c97826b2@github.com>

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Added defaukt namsespace expressions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9906/files
  - new: https://git.openjdk.org/jdk/pull/9906/files/be00c2c6..a75a6dc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9906&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9906&range=01-02

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9906/head:pull/9906

PR: https://git.openjdk.org/jdk/pull/9906

From duke at openjdk.org  Wed Aug 31 21:41:09 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 31 Aug 2022 21:41:09 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v3]
In-Reply-To: <K3YKARq-_Al183mGt7yeJ4PHcXdzmC5oYEkfhyl060k=.0a13a3a6-3596-4a62-b9fd-39f6c97826b2@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
 <K3YKARq-_Al183mGt7yeJ4PHcXdzmC5oYEkfhyl060k=.0a13a3a6-3596-4a62-b9fd-39f6c97826b2@github.com>
Message-ID: <XnQU_g2cdDU1kiAx3NYm05XI6FJsMPOU1m8S4o9xljw=.2d81a121-8f4c-44d1-a4e5-3ae9e45912f6@github.com>

On Wed, 31 Aug 2022 21:17:22 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added defaukt namsespace expressions.

Changes requested by bwhuang-us at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/9906

From duke at openjdk.org  Wed Aug 31 21:41:13 2022
From: duke at openjdk.org (Bill Huang)
Date: Wed, 31 Aug 2022 21:41:13 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v2]
In-Reply-To: <hh8i30_4bIFgNcGOUC4CFfcbNlnw_WvJC_0yRHiW9nY=.42731d9a-1929-4c65-a4f3-b93f38295ae2@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
 <hh8i30_4bIFgNcGOUC4CFfcbNlnw_WvJC_0yRHiW9nY=.42731d9a-1929-4c65-a4f3-b93f38295ae2@github.com>
Message-ID: <Op_ceTbImQz76fmKMzwVBvDeTweLucxP1PLWczm-RbE=.8964c0b4-78e5-4f1e-8cf5-633acf5b6ec2@github.com>

On Thu, 25 Aug 2022 16:58:29 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpNamespaceTest.java line 114:

> 112:                 {"//Customer/Name/namespace::dog", "dog", "xmlns", "xmlns:dog","www.pets.com"},
> 113:                 {"/Customers/Customer/Name/namespace::dog", "dog", "xmlns", "xmlns:dog","www.pets.com"}
> 114:         };

It would good to test an element with a prefix. For example,
`{"//www.foo.com:Customer/namespace::foo", "foo", "xmlns", "xmlns:foo", "www.foo.com"}`

I am not sure if the above expression is a practical use case. We may want to use a more real-world expression.
`"/Customers/*[name()='foo:Customer']/namespace::foo"`

Some other expressions as follows,
`"/Customers/*[namespace-uri()='www.foo.com']/namespace::foo"`
`"/Customers/*[contains(name(.), 'foo:')]/namespace::foo"`
`"/Customers/*[starts-with(name(.), 'foo:')]/namespace::foo"`
`"//*[local-name()='Customer' and namespace-uri()='www.foo.com']/namespace::foo"`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpNamespaceTest.java line 131:

> 129:                 {"//VendCustomer/Address/namespace::street"},
> 130:                 {"/Customers/VendCustomer/Address/namespace::street"}
> 131:         };

It would be good to test empty namespace nodes on attribute nodes. For example,
`"//@id/namespace::*"`
`"//@*[name()='foo:id']/namespace::*"`
`"//@*[local-name()='id' and namespace-uri()='www.foo.com']/namespace::*"`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpNamespaceTest.java line 164:

> 162:                 {"namespace-uri(/Customers/Customer/www.pets.com:Address)","www.pets.com" },
> 163:                 {"namespace-uri(/Customers/VendCustomer/Email)","" }
> 164:         };

It would be good to test namespace-uri() on attributes. For example,
`{"namespace-uri(//@*[name()='id'])", ""}`
`{"namespace-uri(//@*[name()='foo:id'])", "www.foo.com"}`

-------------

PR: https://git.openjdk.org/jdk/pull/9906

From duke at openjdk.org  Wed Aug 31 23:33:58 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Wed, 31 Aug 2022 23:33:58 GMT
Subject: RFR: 8230374: maxOutputSize, instead of javatest.maxOutputSize,
 should be used in TEST.properties
Message-ID: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>

Rewrote javatest.maxOutputSize as maxOutputSize in the TEST.properties file in test/jdk/jdk/lambda to match the same declarations in other TEST.properties files. The jtreg specification with the correct syntax for maxOutputSize is at https://openjdk.org/jtreg/tag-spec.html.

-------------

Commit messages:
 - changed lambda TEST.properties: javatest.maxOutputSize is now maxOutputSize

Changes: https://git.openjdk.org/jdk/pull/10071/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8230374
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10071.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10071/head:pull/10071

PR: https://git.openjdk.org/jdk/pull/10071

From rhalade at openjdk.org  Wed Aug 31 23:33:58 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 31 Aug 2022 23:33:58 GMT
Subject: RFR: 8230374: maxOutputSize, instead of javatest.maxOutputSize,
 should be used in TEST.properties
In-Reply-To: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
References: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
Message-ID: <XdXMhR2gAz7QpQmUbOd3_y3P9R47fcMv389XiDEhWnc=.7a979e5e-4958-4aaf-8ff1-ebefefffff06@github.com>

On Mon, 29 Aug 2022 21:25:29 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Rewrote javatest.maxOutputSize as maxOutputSize in the TEST.properties file in test/jdk/jdk/lambda to match the same declarations in other TEST.properties files. The jtreg specification with the correct syntax for maxOutputSize is at https://openjdk.org/jtreg/tag-spec.html.

Please update description to have the JTReg documentation link which shows correct syntax.

-------------

PR: https://git.openjdk.org/jdk/pull/10071

From duke at openjdk.org  Wed Aug 31 23:33:59 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Wed, 31 Aug 2022 23:33:59 GMT
Subject: RFR: 8230374: maxOutputSize, instead of javatest.maxOutputSize,
 should be used in TEST.properties
In-Reply-To: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
References: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
Message-ID: <6CTeE_ShQpsDwlmuKHWeOaXiFJX4OcW8S1_tzsGyLoc=.8b49ea80-dc8d-49fb-a1ec-de0cc944c6b3@github.com>

On Mon, 29 Aug 2022 21:25:29 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Rewrote javatest.maxOutputSize as maxOutputSize in the TEST.properties file in test/jdk/jdk/lambda to match the same declarations in other TEST.properties files. The jtreg specification with the correct syntax for maxOutputSize is at https://openjdk.org/jtreg/tag-spec.html.

Added the jtreg documentation link to the description.

-------------

PR: https://git.openjdk.org/jdk/pull/10071